一垂睬、 設(shè)計(jì)理念
客戶端頁面緩存（http header中包含Expires/Cache of Control署辉，last modified(304评矩，server不返回body饺藤，客戶端可以繼續(xù)用cache剑辫，減少流量)干旧，ETag）
反向代理緩存
應(yīng)用端的緩存(memcache)
內(nèi)存數(shù)據(jù)庫
Buffer、cache機(jī)制（數(shù)據(jù)庫妹蔽，中間件等）
哈希椎眯、B樹、倒排胳岂、bitmap
哈希索引適合綜合數(shù)組的尋址和鏈表的插入特性编整，可以實(shí)現(xiàn)數(shù)據(jù)的快速存取。
B樹索引適合于查詢?yōu)橹鲗?dǎo)的場景乳丰，避免多次的IO掌测，提高查詢的效率。
倒排索引實(shí)現(xiàn)單詞到文檔映射關(guān)系的最佳實(shí)現(xiàn)方式和最有效的索引結(jié)構(gòu)产园，廣泛用在搜索領(lǐng)域汞斧。
Bitmap是一種非常簡潔快速的數(shù)據(jù)結(jié)構(gòu)夜郁，他能同時(shí)使存儲空間和速度最優(yōu)化（而不必空間換時(shí)間），適合于海量數(shù)據(jù)的的計(jì)算場景粘勒。
在大規(guī)模的數(shù)據(jù)中，數(shù)據(jù)存在一定的局部性的特征庙睡，利用局部性的原理將海量數(shù)據(jù)計(jì)算的問題分而治之事富。
MR模型是無共享的架構(gòu)，數(shù)據(jù)集分布至各個節(jié)點(diǎn)埃撵。處理時(shí)赵颅，每個節(jié)點(diǎn)就近讀取本地存儲的數(shù)據(jù)處理(map)，將處理后的數(shù)據(jù)進(jìn)行合并(combine)暂刘、排序(shuffle and sort)后再分發(fā)(至reduce節(jié)點(diǎn))饺谬，避免了大量數(shù)據(jù)的傳輸，提高了處理效率谣拣。
2)多進(jìn)程募寨、多線程并行執(zhí)行(MPP)
并行計(jì)算（Parallel Computing）是指同時(shí)使用多種計(jì)算資源解決計(jì)算問題的過程，是提高計(jì)算機(jī)系統(tǒng)計(jì)算速度和處理能力的一種有效手段森缠。它的基本思想是用多個處理器/進(jìn)程/線程來協(xié)同求解同一問題拔鹰，即將被求解的問題分解成若干個部分，各部分均由一個獨(dú)立的處理機(jī)來并行計(jì)算贵涵。
和MR的區(qū)別在于列肢，它是基于問題分解的，而不是基于數(shù)據(jù)分解宾茂。
隨著平臺并發(fā)量的增大跨晴，需要擴(kuò)容節(jié)點(diǎn)進(jìn)行集群欧聘，利用負(fù)載均衡設(shè)備進(jìn)行請求的分發(fā)；負(fù)載均衡設(shè)備通常在提供負(fù)載均衡的同時(shí)端盆，也提供失效檢測功能怀骤；同時(shí)為了提高可用性，需要有容災(zāi)備份焕妙，以防止節(jié)點(diǎn)宕機(jī)失效帶來的不可用問題蒋伦；備份有在線的和離線備份，可以根據(jù)失效性要求的不同访敌，進(jìn)行選擇不同的備份策略凉敲。
讀寫分離是對數(shù)據(jù)庫來講的，隨著系統(tǒng)并發(fā)量的增大寺旺，提高數(shù)據(jù)訪問可用性的一個重要手段就是寫數(shù)據(jù)和讀數(shù)據(jù)進(jìn)行分離爷抓；當(dāng)然在讀寫分離的同時(shí)，需要關(guān)注數(shù)據(jù)的一致性問題阻塑；對于一致性的問題蓝撇，在分布式的系統(tǒng)CAP定量中，更多的關(guān)注于可用性陈莽。
平臺中各個模塊之間的關(guān)系盡量是低耦合的渤昌，可以通過相關(guān)的消息組件進(jìn)行交互，能異步則異步走搁，分清楚數(shù)據(jù)流轉(zhuǎn)的主流程和副流程独柑，主副是異步的，比如記錄日志可以是異步操作的私植，增加整個系統(tǒng)的可用性忌栅。
當(dāng)然在異步處理中，為了確保數(shù)據(jù)得到接收或者處理曲稼，往往需要確認(rèn)機(jī)制(confirm索绪、ack)。
但是有些場景中贫悄，雖然請求已經(jīng)得到處理瑞驱，但是因其他原因(比如網(wǎng)絡(luò)不穩(wěn)定)，確認(rèn)消息沒有返回窄坦，那么這種情況下需要進(jìn)行請求的重發(fā)唤反，對請求的處理設(shè)計(jì)因重發(fā)因素需要考慮冪等性。
監(jiān)控也是提高整個平臺可用性的一個重要手段鸭津，多平臺進(jìn)行多個維度的監(jiān)控彤侍；模塊在運(yùn)行時(shí)候是透明的，以達(dá)到運(yùn)行期白盒化曙博。
拆分包括對業(yè)務(wù)的拆分和對數(shù)據(jù)庫的拆分拥刻。
系統(tǒng)的資源總是有限的，一段比較長的業(yè)務(wù)執(zhí)行如果是一竿子執(zhí)行的方式父泳，在大量并發(fā)的操作下般哼，這種阻塞的方式，無法有效的及時(shí)釋放資源給其他進(jìn)程執(zhí)行惠窄，這樣系統(tǒng)的吞吐量不高蒸眠。
需要把業(yè)務(wù)進(jìn)行邏輯的分段，采用異步非阻塞的方式杆融，提高系統(tǒng)的吞吐量楞卡。
隨著數(shù)據(jù)量和并發(fā)量的增加，讀寫分離不能滿足系統(tǒng)并發(fā)性能的要求，需要對數(shù)據(jù)進(jìn)行切分蒋腮，包括對數(shù)據(jù)進(jìn)行分庫和分表淘捡。這種分庫分表的方式，需要增加對數(shù)據(jù)的路由邏輯支持池摧。
對于系統(tǒng)的伸縮性而言焦除，模塊最好是無狀態(tài)的，通過增加節(jié)點(diǎn)就可以提高整個的吞吐量作彤。
系統(tǒng)的容量是有限的膘魄，承受的并發(fā)量也是有限的，在架構(gòu)設(shè)計(jì)時(shí)竭讳，一定需要考慮流量的控制创葡，防止因意外攻擊或者瞬時(shí)并發(fā)量的沖擊導(dǎo)致系統(tǒng)崩潰。在設(shè)計(jì)時(shí)增加流控的措施绢慢，可考慮對請求進(jìn)行排隊(duì)灿渴，超出預(yù)期的范圍，可以進(jìn)行告警或者丟棄呐芥。
對于共享資源的訪問逻杖，為了防止沖突，需要進(jìn)行并發(fā)的控制思瘟，同時(shí)有些交易需要有事務(wù)性來保證交易的一致性荸百，所以在交易系統(tǒng)的設(shè)計(jì)時(shí)，需考慮原子操作和并發(fā)控制滨攻。
保證并發(fā)控制一些常用高性能手段有够话，樂觀鎖、Latch光绕、mutex女嘲、寫時(shí)復(fù)制、CAS等诞帐；多版本的并發(fā)控制MVCC通常是保證一致性的重要手段欣尼，這個在數(shù)據(jù)庫的設(shè)計(jì)中經(jīng)常會用到。
平臺中業(yè)務(wù)邏輯存在不同的類型愕鼓，有計(jì)算復(fù)雜型的，有消耗IO型的慧起，同時(shí)就同一種類型而言菇晃，不同的業(yè)務(wù)邏輯消耗的資源數(shù)量也是不一樣的，這就需要針對不同的邏輯采取不同的策略蚓挤。
針對IO型的磺送，可以采取基于事件驅(qū)動的異步非阻塞的方式驻子，單線程方式可以減少線程的切換引起的開銷，或者在多線程的情況下采取自旋spin的方式估灿，減少對線程的切換(比如Oraclelatch設(shè)計(jì))崇呵；對于計(jì)算型的，充分利用多線程進(jìn)行操作甲捏。
同一類型的調(diào)用方式演熟，不同的業(yè)務(wù)進(jìn)行合適的資源分配鞭执，設(shè)置不同的計(jì)算節(jié)點(diǎn)數(shù)量或者線程數(shù)量司顿，對業(yè)務(wù)進(jìn)行分流，優(yōu)先執(zhí)行優(yōu)先級別高的業(yè)務(wù)兄纺。
系統(tǒng)的有些業(yè)務(wù)模塊在出現(xiàn)錯誤時(shí)大溜，為了減少并發(fā)下對正常請求的處理的影響，有時(shí)候需要考慮對這些異常狀態(tài)的請求進(jìn)行單獨(dú)渠道的處理估脆，甚至?xí)簳r(shí)自動禁止這些異常的業(yè)務(wù)模塊钦奋。
有些請求的失敗可能是偶然的暫時(shí)的失敗(比如網(wǎng)絡(luò)不穩(wěn)定)，需要進(jìn)行請求重試的考慮疙赠。
系統(tǒng)的資源是有限的付材，在使用資源時(shí)，一定要在最后釋放資源圃阳，無論是請求走的是正常路徑還是異常的路徑厌衔，以便于資源的及時(shí)回收，供其他請求使用捍岳。
在設(shè)計(jì)通信的架構(gòu)時(shí)富寿，往往需要考慮超時(shí)的控制。
整個架構(gòu)是分層的分布式的架構(gòu)页徐，縱向包括CDN，負(fù)載均衡/反向代理银萍，web應(yīng)用变勇，業(yè)務(wù)層，基礎(chǔ)服務(wù)層贴唇，數(shù)據(jù)存儲層搀绣。水平方向包括對整個平臺的配置管理部署和監(jiān)控。
CDN系統(tǒng)能夠?qū)崟r(shí)地根據(jù)網(wǎng)絡(luò)流量和各節(jié)點(diǎn)的連接豌熄、負(fù)載狀況以及到用戶的距離和響應(yīng)時(shí)間等綜合信息將用戶的請求重新導(dǎo)向離用戶最近的服務(wù)節(jié)點(diǎn)上。其目的是使用戶可就近取得所需內(nèi)容物咳，解決Internet網(wǎng)絡(luò)擁擠的狀況锣险，提高用戶訪問網(wǎng)站的響應(yīng)速度蹄皱。
對于大規(guī)模電子商務(wù)平臺一般需要建CDN做網(wǎng)絡(luò)加速，大型平臺如淘寶芯肤、京東都采用自建CDN巷折，中小型的企業(yè)可以采用第三方CDN廠商合作，如藍(lán)汛崖咨、網(wǎng)宿锻拘、快網(wǎng)等。
當(dāng)然在選擇CDN廠商時(shí)击蹲，需要考慮經(jīng)營時(shí)間長短署拟，是否有可擴(kuò)充的帶寬資源、靈活的流量和帶寬選擇歌豺、穩(wěn)定的節(jié)點(diǎn)推穷、性價(jià)比。
一個大型的平臺包括很多個業(yè)務(wù)域馒铃，不同的業(yè)務(wù)域有不同的集群，可以用DNS做域名解析的分發(fā)或輪詢痕惋，DNS方式實(shí)現(xiàn)簡單区宇，但是因存在cache而缺乏靈活性；一般基于商用的硬件F5值戳、NetScaler或者開源的軟負(fù)載lvs在4層做分發(fā)议谷，當(dāng)然會采用做冗余(比如lvs+keepalived)的考慮，采取主備方式述寡。
4層分發(fā)到業(yè)務(wù)集群上后柿隙，會經(jīng)過web服務(wù)器如nginx或者HAProxy在7層做負(fù)載均衡或者反向代理分發(fā)到集群中的應(yīng)用節(jié)點(diǎn)。
選擇哪種負(fù)載鲫凶，需要綜合考慮各種因素（是否滿足高并發(fā)高性能禀崖，Session保持如何解決，負(fù)載均衡的算法如何螟炫，支持壓縮波附，緩存的內(nèi)存消耗）；下面基于幾種常用的負(fù)載均衡軟件做個介紹昼钻。
LVS掸屡，工作在4層，Linux實(shí)現(xiàn)的高性能高并發(fā)然评、可伸縮性仅财、可靠的的負(fù)載均衡器，支持多種轉(zhuǎn)發(fā)方式(NAT碗淌、DR盏求、IP?Tunneling)抖锥，其中DR模式支持通過廣域網(wǎng)進(jìn)行負(fù)載均衡。支持雙機(jī)熱備(Keepalived或者Heartbeat)碎罚。對網(wǎng)絡(luò)環(huán)境的依賴性比較高磅废。
Nginx工作在7層，事件驅(qū)動的荆烈、異步非阻塞的架構(gòu)拯勉、支持多進(jìn)程的高并發(fā)的負(fù)載均衡器/反向代理軟件琴昆×模可以針對域名、目錄結(jié)構(gòu)朋其、正則規(guī)則針對http做一些分流倦始。通過端口檢測到服務(wù)器內(nèi)部的故障斗遏，比如根據(jù)服務(wù)器處理網(wǎng)頁返回的狀態(tài)碼、超時(shí)等等鞋邑，并且會把返回錯誤的請求重新提交到另一個節(jié)點(diǎn)，不過其中缺點(diǎn)就是不支持url來檢測账蓉。對于session?sticky枚碗，可以基于ip?hash的算法來實(shí)現(xiàn)，通過基于cookie的擴(kuò)展nginx-sticky-module支持session sticky铸本。
HAProxy支持4層和7層做負(fù)載均衡肮雨，支持session的會話保持，cookie的引導(dǎo)箱玷；支持后端url方式的檢測怨规；負(fù)載均衡的算法比較豐富，有RR锡足、權(quán)重等波丰。
對于圖片，需要有單獨(dú)的域名舶得，獨(dú)立或者分布式的圖片服務(wù)器或者如mogileFS掰烟，可以圖片服務(wù)器之上加varnish做圖片緩存。
應(yīng)用層運(yùn)行在jboss或者tomcat容器中沐批，代表獨(dú)立的系統(tǒng)纫骑，比如前端購物、用戶自主服務(wù)九孩、后端系統(tǒng)等
協(xié)議接口先馆，HTTP、JSON
可以采用servlet3.0,異步化servlet,提高整個系統(tǒng)的吞吐量
http請求經(jīng)過Nginx躺彬，通過負(fù)載均衡算法分到到App的某一節(jié)點(diǎn)煤墙，這一層層擴(kuò)容起來比較簡單缤底。
除了利用cookie保存少量用戶部分信息外(cookie一般不能超過4K的大小)，對于App接入層番捂，保存有用戶相關(guān)的session數(shù)據(jù)个唧，但是有些反向代理或者負(fù)載均衡不支持對session?sticky支持不是很好或者對接入的可用性要求比較高(app接入節(jié)點(diǎn)宕機(jī)，session隨之丟失)设预，這就需要考慮session的集中式存儲徙歼，使得App接入層無狀態(tài)化，同時(shí)系統(tǒng)用戶變多的時(shí)候鳖枕，就可以通過增加更多的應(yīng)用節(jié)點(diǎn)來達(dá)到水平擴(kuò)展的目的魄梯。
Session的集中式存儲，需要滿足以下幾點(diǎn)要求：
a宾符、高效的通訊協(xié)議
b酿秸、session的分布式緩存，支持節(jié)點(diǎn)的伸縮魏烫，數(shù)據(jù)的冗余備份以及數(shù)據(jù)的遷移
c辣苏、session過期的管理
代表某一領(lǐng)域的業(yè)務(wù)提供的服務(wù)，對于電商而言哄褒，領(lǐng)域有用戶稀蟋、商品、訂單呐赡、紅包退客、支付業(yè)務(wù)等等，不同的領(lǐng)域提供不同的服務(wù)链嘀，
這些不同的領(lǐng)域構(gòu)成一個個模塊萌狂，良好的模塊劃分和接口設(shè)計(jì)非常重要，一般是參考高內(nèi)聚怀泊、接口收斂的原則茫藏，
這樣可以提高整個系統(tǒng)的可用性。當(dāng)然可以根據(jù)應(yīng)用規(guī)模的大小包个，模塊可以部署在一起刷允，對于大規(guī)模的應(yīng)用，一般是獨(dú)立部署的碧囊。
高并發(fā)：
業(yè)務(wù)層對外協(xié)議以NIO的RPC方式暴露树灶，可以采用比較成熟的NIO通訊框架，如netty糯而、mina
可用性：
為了提高模塊服務(wù)的可用性天通，一個模塊部署在多個節(jié)點(diǎn)做冗余，并自動進(jìn)行負(fù)載轉(zhuǎn)發(fā)和失效轉(zhuǎn)移;
最初可以利用VIP+heartbeat方式熄驼，目前系統(tǒng)有一個單獨(dú)的組件HA,利用zookeeper實(shí)現(xiàn)(比原來方案的優(yōu)點(diǎn))
一致性像寒、事務(wù)：
對于分布式系統(tǒng)的一致性烘豹，盡量滿足可用性，一致性可以通過校對來達(dá)到最終一致的狀態(tài)诺祸。
通信組件用于業(yè)務(wù)系統(tǒng)內(nèi)部服務(wù)之間的調(diào)用携悯，在大并發(fā)的電商平臺中，需要滿足高并發(fā)高吞吐量的要求筷笨。
整個通信組件包括客戶端和服務(wù)端兩部分憔鬼。
客戶端和服務(wù)器端維護(hù)的是長連接，可以減少每次請求建立連接的開銷胃夏，在客戶端對于每個服務(wù)器定義一個連接池轴或，初始化連接后，可以并發(fā)連接服務(wù)端進(jìn)行rpc操作仰禀，連接池中的長連接需要心跳維護(hù)照雁，設(shè)置請求超時(shí)時(shí)間。
對于長連接的維護(hù)過程可以分兩個階段答恶，一個是發(fā)送請求過程饺蚊，另外一個是接收響應(yīng)過程。在發(fā)送請求過程中亥宿，若發(fā)生IOException卸勺，則把該連接標(biāo)記失效。接收響應(yīng)時(shí)烫扼，服務(wù)端返回SocketTimeoutException，如果設(shè)置了超時(shí)時(shí)間碍庵，那么就直接返回異常映企，清除當(dāng)前連接中那些超時(shí)的請求。否則繼續(xù)發(fā)送心跳包(因?yàn)榭赡苁莵G包静浴，超過pingInterval間隔時(shí)間就發(fā)送ping操作)堰氓，若ping不通(發(fā)送IOException)，則說明當(dāng)前連接是有問題的苹享，那么就把當(dāng)前連接標(biāo)記成已經(jīng)失效双絮；若ping通，則說明當(dāng)前連接是可靠的得问，繼續(xù)進(jìn)行讀操作囤攀。失效的連接會從連接池中清除掉。
每個連接對于接收響應(yīng)來說都以單獨(dú)的線程運(yùn)行宫纬，客戶端可以通過同步(wait,notify)方式或者異步進(jìn)行rpc調(diào)用焚挠，
序列化采用更高效的hession序列化方式。
服務(wù)端采用事件驅(qū)動的NIO的MINA框架漓骚，支撐高并發(fā)高吞吐量的請求蝌衔。
在大多數(shù)的數(shù)據(jù)庫切分解決方案中榛泛，為了提高數(shù)據(jù)庫的吞吐量，首先是對不同的表進(jìn)行垂直切分到不同的數(shù)據(jù)庫中噩斟，
然后當(dāng)數(shù)據(jù)庫中一個表超過一定大小時(shí)曹锨，需要對該表進(jìn)行水平切分，這里也是一樣剃允，這里以用戶表為例沛简；
對于訪問數(shù)據(jù)庫客戶端來講，需要根據(jù)用戶的ID硅急，定位到需要訪問的數(shù)據(jù)覆享；
數(shù)據(jù)切分算法，
根據(jù)用戶的ID做hash操作营袜，一致性Hash撒顿，這種方式存在失效數(shù)據(jù)的遷移問題，遷移時(shí)間內(nèi)服務(wù)不可用
維護(hù)路由表荚板，路由表中存儲用戶和sharding的映射關(guān)系,sharding分為leader和replica凤壁，分別負(fù)責(zé)寫和讀
這樣每個biz客戶端都需要保持所有sharding的連接池，這樣有個缺點(diǎn)是會產(chǎn)生全連接的問題跪另；
一種解決方法是sharding的切分提到業(yè)務(wù)服務(wù)層進(jìn)行拧抖，每個業(yè)務(wù)節(jié)點(diǎn)只維護(hù)一個shard的連接即可。
見圖（router）
路由組件的實(shí)現(xiàn)是這樣的（可用性免绿、高性能唧席、高并發(fā)）
基于性能方面的考慮，采用MongoDB中維護(hù)用戶id和shard的關(guān)系嘲驾，為了保證可用性淌哟，搭建replicatset集群。
biz的sharding和數(shù)據(jù)庫的sharding是一一對應(yīng)的辽故，只訪問一個數(shù)據(jù)庫sharding.
biz業(yè)務(wù)注冊節(jié)點(diǎn)到zookeeper上/bizs/shard/下徒仓。
router監(jiān)聽zookeeper上/bizs/下節(jié)點(diǎn)狀態(tài)，緩存在線biz在router中誊垢。
client請求router獲取biz時(shí)掉弛，router首先從mongodb中獲取用戶對應(yīng)的shard,router根據(jù)緩存的內(nèi)容通過RR算法獲取biz節(jié)點(diǎn)。
為了解決router的可用性和并發(fā)吞吐量問題喂走，對router進(jìn)行冗余殃饿，同時(shí)client監(jiān)聽zookeeper的/routers節(jié)點(diǎn)并緩存在線router節(jié)點(diǎn)列表。
傳統(tǒng)實(shí)現(xiàn)HA的做法一般是采用虛擬IP漂移缴啡，結(jié)合Heartbeat壁晒、keepalived等實(shí)現(xiàn)HA，
Keepalived使用vrrp方式進(jìn)行數(shù)據(jù)包的轉(zhuǎn)發(fā)，提供4層的負(fù)載均衡秒咐，通過檢測vrrp數(shù)據(jù)包來切換谬晕，做冗余熱備更加適合與LVS搭配。Linux?Heartbeat是基于網(wǎng)絡(luò)或者主機(jī)的服務(wù)的高可用携取，HAProxy或者Nginx可以基于7層進(jìn)行數(shù)據(jù)包的轉(zhuǎn)發(fā)攒钳，因此Heatbeat更加適合做HAProxy、Nginx雷滋，包括業(yè)務(wù)的高可用不撑。
在分布式的集群中，可以用zookeeper做分布式的協(xié)調(diào)晤斩，實(shí)現(xiàn)集群的列表維護(hù)和失效通知焕檬，客戶端可以選擇hash算法或者roudrobin實(shí)現(xiàn)負(fù)載均衡；對于master-master模式澳泵、master-slave模式实愚，可以通過zookeeper分布式鎖的機(jī)制來支持。
對于平臺各個系統(tǒng)之間的異步交互兔辅，是通過MQ組件進(jìn)行的腊敲。
在設(shè)計(jì)消息服務(wù)組件時(shí)，需要考慮消息一致性维苔、持久化碰辅、可用性、以及完善的監(jiān)控體系介时。
業(yè)界開源的消息中間件主要RabbitMQ没宾、kafka有兩種，
RabbitMQ,遵循AMQP協(xié)議沸柔，由內(nèi)在高并發(fā)的erlanng語言開發(fā)榕吼；kafka是Linkedin于2010年12月份開源的消息發(fā)布訂閱系統(tǒng),它主要用于處理活躍的流式數(shù)據(jù),大數(shù)據(jù)量的數(shù)據(jù)處理上。
對消息一致性要求比較高的場合需要有應(yīng)答確認(rèn)機(jī)制勉失，包括生產(chǎn)消息和消費(fèi)消息的過程；不過因網(wǎng)絡(luò)等原理導(dǎo)致的應(yīng)答缺失原探，可能會導(dǎo)致消息的重復(fù)乱凿，這個可以在業(yè)務(wù)層次根據(jù)冪等性進(jìn)行判斷過濾；RabbitMQ采用的是這種方式咽弦。還有一種機(jī)制是消費(fèi)端從broker拉取消息時(shí)帶上LSN號徒蟆，從broker中某個LSN點(diǎn)批量拉取消息，這樣無須應(yīng)答機(jī)制型型，kafka分布式消息中間件就是這種方式段审。
消息的在broker中的存儲，根據(jù)消息的可靠性的要求以及性能方面的綜合衡量闹蒜，可以在內(nèi)存中寺枉，可以持久化到存儲上抑淫。
對于可用性和高吞吐量的要求，集群和主備模式都可以在實(shí)際的場景應(yīng)用的到姥闪。RabbitMQ解決方案中有普通的集群和可用性更高的mirror?queue方式始苇。kafka采用zookeeper對集群中的broker、consumer進(jìn)行管理筐喳，可以注冊topic到zookeeper上催式；通過zookeeper的協(xié)調(diào)機(jī)制，producer保存對應(yīng)topic的broker信息避归，可以隨機(jī)或者輪詢發(fā)送到broker上荣月；并且producer可以基于語義指定分片，消息發(fā)送到broker的某分片上梳毙。
總體來講哺窄，RabbitMQ用在實(shí)時(shí)的對可靠性要求比較高的消息傳遞上。kafka主要用于處理活躍的流式數(shù)據(jù),大數(shù)據(jù)量的數(shù)據(jù)處理上顿天。
Cache系統(tǒng)
在一些高并發(fā)高性能的場景中堂氯，使用cache可以減少對后端系統(tǒng)的負(fù)載，承擔(dān)可大部分讀的壓力牌废，可以大大提高系統(tǒng)的吞吐量咽白，比如通常在數(shù)據(jù)庫存儲之前增加cache緩存。
但是引入cache架構(gòu)不可避免的帶來一些問題鸟缕，cache命中率的問題,?cache失效引起的抖動晶框，cache和存儲的一致性。
Cache中的數(shù)據(jù)相對于存儲來講懂从，畢竟是有限的授段，比較理想的情況是存儲系統(tǒng)的熱點(diǎn)數(shù)據(jù)，這里可以用一些常見的算法LRU等等淘汰老的數(shù)據(jù)番甩；隨著系統(tǒng)規(guī)模的增加侵贵，單個節(jié)點(diǎn)cache不能滿足要求，就需要搭建分布式Cache缘薛；為了解決單個節(jié)點(diǎn)失效引起的抖動?窍育，分布式cache一般采用一致性hash的解決方案，大大減少因單個節(jié)點(diǎn)失效引起的抖動范圍宴胧；而對于可用性要求比較高的場景漱抓，每個節(jié)點(diǎn)都是需要有備份的。數(shù)據(jù)在cache和存儲上都存有同一份備份恕齐，必然有一致性的問題乞娄，一致性比較強(qiáng)的，在更新數(shù)據(jù)庫的同時(shí)，更新數(shù)據(jù)庫cache仪或。對于一致性要求不高的确镊，可以去設(shè)置緩存失效時(shí)間的策略。
Memcached作為高速的分布式緩存服務(wù)器溶其，協(xié)議比較簡單骚腥，基于libevent的事件處理機(jī)制。
Cache系統(tǒng)在平臺中用在router系統(tǒng)的客戶端中瓶逃，熱點(diǎn)的數(shù)據(jù)會緩存在客戶端束铭，當(dāng)數(shù)據(jù)訪問失效時(shí)，才去訪問router系統(tǒng)厢绝。
當(dāng)然目前更多的利用內(nèi)存型的數(shù)據(jù)庫做cache契沫，比如Redis、mongodb昔汉；redis比memcache有豐富的數(shù)據(jù)操作的API懈万；redis和mongodb都對數(shù)據(jù)進(jìn)行了持久化，而memcache沒有這個功能靶病，因此memcache更加適合在關(guān)系型數(shù)據(jù)庫之上的數(shù)據(jù)的緩存会通。
Buffer系統(tǒng)
用在高速的寫操作的場景中，平臺中有些數(shù)據(jù)需要寫入數(shù)據(jù)庫娄周，并且數(shù)據(jù)是分庫分表的涕侈，但對數(shù)據(jù)的可靠性不是那么高，為了減少對數(shù)據(jù)庫的寫壓力煤辨，可以采取批量寫操作的方式裳涛。
開辟一個內(nèi)存區(qū)域，當(dāng)數(shù)據(jù)到達(dá)區(qū)域的一定閥值時(shí)如80%時(shí)众辨，在內(nèi)存中做分庫梳理工作(內(nèi)存速度還是比較快的)端三，后分庫批量flush。
在電子商務(wù)平臺中搜索是一個非常的重要功能鹃彻，主要有搜索詞類目導(dǎo)航郊闯、自動提示和搜索排序功能。
開源的企業(yè)級搜索引擎主要有l(wèi)ucene,sphinx蛛株，這里不去論述哪種搜索引擎更好一些虚婿，不過選擇搜索引擎除了基本的功能需要支持外，非功能方面需要考慮以下兩點(diǎn)：
a泳挥、?搜索引擎是否支持分布式的索引和搜索，來應(yīng)對海量的數(shù)據(jù)至朗，支持讀寫分離屉符，提高可用性
b、?索引的實(shí)時(shí)性
c、?性能
Solr是基于lucene的高性能的全文搜索服務(wù)器矗钟，提供了比lucene更為豐富的查詢語言唆香，可配置可擴(kuò)展，對外提供基于http協(xié)議的XML/JSON格式的接口吨艇。
從Solr4版本開始提供了SolrCloud方式來支持分布式的索引躬它，自動進(jìn)行sharding數(shù)據(jù)切分；通過每個sharding的master-slave(leader东涡、replica)模式提高搜索的性能冯吓；利用zookeeper對集群進(jìn)行管理，包括leader選舉等等疮跑，保障集群的可用性组贺。
Lucene索引的Reader是基于索引的snapshot的，所以必須在索引commit的后祖娘，重新打開一個新的snapshot失尖，才能搜索到新添加的內(nèi)容；而索引的commit是非常耗性能的渐苏，這樣達(dá)到實(shí)時(shí)索引搜索效率就比較低下掀潮。
對于索引搜索實(shí)時(shí)性，Solr4的之前解決方案是結(jié)合文件全量索引和內(nèi)存增量索引合并的方式琼富，參見下圖仪吧。
Solr4提供了NRT?softcommit的解決方案，softcommit無需進(jìn)行提交索引操作公黑，就可以搜素到最新對索引的變更邑商，不過對索引的變更并沒有sync?commit到硬盤存儲上，若發(fā)生意外導(dǎo)致程序非正常結(jié)束凡蚜，未commit的數(shù)據(jù)會丟失人断，因此需要定時(shí)的進(jìn)行commit操作。
平臺中對數(shù)據(jù)的索引和存儲操作是異步的朝蜘，可以大大提高可用性和吞吐量恶迈；只對某些屬性字段做索引操作，存儲數(shù)據(jù)的標(biāo)識key谱醇，減少索引的大邢局佟；數(shù)據(jù)是存儲在分布式存儲Hbase中的副渴，HBase對二級索引搜索支持的不好奈附，然而可以結(jié)合Solr搜索功能進(jìn)行多維度的檢索統(tǒng)計(jì)。
索引數(shù)據(jù)和HBase數(shù)據(jù)存儲的一致性煮剧，也就是如何保障HBase存儲的數(shù)據(jù)都被索引過斥滤，可以采用confirm確認(rèn)機(jī)制将鸵，通過在索引前建立待索引數(shù)據(jù)隊(duì)列，在數(shù)據(jù)存儲并索引完成后佑颇，從待索引數(shù)據(jù)隊(duì)列中刪除數(shù)據(jù)顶掉。
在整個交易過程中，會產(chǎn)生大量的日志挑胸，這些日志需要收集到分布式存儲系統(tǒng)中存儲起來痒筒，以便于集中式的查詢和分析處理。
日志系統(tǒng)需具備三個基本組件茬贵，分別為agent（封裝數(shù)據(jù)源簿透，將數(shù)據(jù)源中的數(shù)據(jù)發(fā)送給collector），collector（接收多個agent的數(shù)據(jù)闷沥，并進(jìn)行匯總后導(dǎo)入后端的store中）萎战，store（中央存儲系統(tǒng)，應(yīng)該具有可擴(kuò)展性和可靠性舆逃，應(yīng)該支持當(dāng)前非常流行的HDFS）蚂维。
開源的日志收集系統(tǒng)業(yè)界使用的比較多的是cloudera的Flume和facebook的Scribe，其中Flume目前的版本FlumeNG對Flume從架構(gòu)上做了較大的改動路狮。
在設(shè)計(jì)或者對日志收集系統(tǒng)做技術(shù)選型時(shí)虫啥，通常需要具有以下特征：
a、?應(yīng)用系統(tǒng)和分析系統(tǒng)之間的橋梁奄妨，將他們之間的關(guān)系解耦
b涂籽、?分布式可擴(kuò)展，具有高的擴(kuò)展性砸抛，當(dāng)數(shù)據(jù)量增加時(shí)评雌，可以通過增加節(jié)點(diǎn)水平擴(kuò)展
日志收集系統(tǒng)是可以伸縮的，在系統(tǒng)的各個層次都可伸縮直焙，對數(shù)據(jù)的處理不需要帶狀態(tài)景东，伸縮性方面也比較容易實(shí)現(xiàn)。
c奔誓、?近實(shí)時(shí)性
在一些時(shí)效性要求比較高的場景中斤吐，需要可以及時(shí)的收集日志，進(jìn)行數(shù)據(jù)分析厨喂；
一般的日志文件都會定時(shí)或者定量的進(jìn)行rolling和措，所以實(shí)時(shí)檢測日志文件的生成，及時(shí)對日志文件進(jìn)行類似的tail操作蜕煌，并支持批量發(fā)送提高傳輸效率派阱；批量發(fā)送的時(shí)機(jī)需要滿足消息數(shù)量和時(shí)間間隔的要求。
d斜纪、?容錯性
Scribe在容錯方面的考慮是颁褂，當(dāng)后端的存儲系統(tǒng)crash時(shí)故响，scribe會將數(shù)據(jù)寫到本地磁盤上，當(dāng)存儲系統(tǒng)恢復(fù)正常后颁独，scribe將日志重新加載到存儲系統(tǒng)中。
FlumeNG通過Sink?Processor實(shí)現(xiàn)負(fù)載均衡和故障轉(zhuǎn)移伪冰。多個Sink可以構(gòu)成一個Sink?Group誓酒。一個Sink?Processor負(fù)責(zé)從一個指定的Sink?Group中激活一個Sink。Sink?Processor可以通過組中所有Sink實(shí)現(xiàn)負(fù)載均衡贮聂；也可以在一個Sink失敗時(shí)轉(zhuǎn)移到另一個靠柑。
e、?事務(wù)支持
Scribe沒有考慮事務(wù)的支持吓懈。
Flume通過應(yīng)答確認(rèn)機(jī)制實(shí)現(xiàn)事務(wù)的支持歼冰，參見下圖，
通常提取發(fā)送消息都是批量操作的耻警，消息的確認(rèn)是對一批數(shù)據(jù)的確認(rèn)隔嫡，這樣可以大大提高數(shù)據(jù)發(fā)送的效率。
f甘穿、?可恢復(fù)性
FlumeNG的channel根據(jù)可靠性的要求的不同腮恩，可以基于內(nèi)存和文件持久化機(jī)制，基于內(nèi)存的數(shù)據(jù)傳輸?shù)匿N量比較高温兼，但是在節(jié)點(diǎn)宕機(jī)后秸滴，數(shù)據(jù)丟失攀唯，不可恢復(fù)抚恒；而文件持久化宕機(jī)是可以恢復(fù)的填物。
g认然、?數(shù)據(jù)的定時(shí)定量歸檔
數(shù)據(jù)經(jīng)過日志收集系統(tǒng)歸集后工坊，一般存儲在分布式文件系統(tǒng)如Hadoop聪全，為了便于對數(shù)據(jù)進(jìn)行后續(xù)的處理分析熏矿，需要定時(shí)(TimeTrigger)或者定量(SizeTrigger的rolling分布式系統(tǒng)的文件制轰。
在交易系統(tǒng)中敦腔，通常需要進(jìn)行異構(gòu)數(shù)據(jù)源的同步均澳，通常有數(shù)據(jù)文件到關(guān)系型數(shù)據(jù)庫，數(shù)據(jù)文件到分布式數(shù)據(jù)庫符衔，關(guān)系型數(shù)據(jù)庫到分布式數(shù)據(jù)庫等找前。數(shù)據(jù)在異構(gòu)源之間的同步一般是基于性能和業(yè)務(wù)的需求，數(shù)據(jù)存儲在本地文件中一般是基于性能的考慮判族，文件是順序存儲的躺盛，效率還是比較高的；數(shù)據(jù)同步到關(guān)系型數(shù)據(jù)一般是基于查詢的需求形帮；而分布式數(shù)據(jù)庫是存儲越來越多的海量數(shù)據(jù)的槽惫，而關(guān)系型數(shù)據(jù)庫無法滿足大數(shù)據(jù)量的存儲和查詢請求周叮。
在數(shù)據(jù)同步的設(shè)計(jì)中需要綜合考慮吞吐量、容錯性界斜、可靠性仿耽、一致性的問題
同步有實(shí)時(shí)增量數(shù)據(jù)同步和離線全量數(shù)據(jù)區(qū)分，下面從這兩個維度來介紹一下各薇，
實(shí)時(shí)增量一般是Tail文件來實(shí)時(shí)跟蹤文件變化项贺，批量或者多線程往數(shù)據(jù)庫導(dǎo)出,這種方式的架構(gòu)類似于日志收集框架。這種方式需要有確認(rèn)機(jī)制峭判，包括兩個方面开缎。
一個方面是Channel需要給agent確認(rèn)已經(jīng)批量收到數(shù)據(jù)記錄了，發(fā)送LSN號給agent林螃，這樣在agent失效恢復(fù)時(shí)奕删，可以從這個LSN點(diǎn)開始tail；當(dāng)然對于允許少量的重復(fù)記錄的問題(發(fā)生在channel給agent確認(rèn)的時(shí)疗认，agent宕機(jī)并未受到確認(rèn)消息)完残，需要在業(yè)務(wù)場景中判斷。
另外一個方面是sync給channel確認(rèn)已經(jīng)批量完成寫入到數(shù)據(jù)庫的操作侮邀，這樣channel可以刪除這部分已經(jīng)confirm的消息坏怪。
基于可靠性的要求，channel可以采用文件持久化的方式绊茧。
參見下圖
離線全量遵循空間間換取時(shí)間铝宵，分而治之的原則，盡量的縮短數(shù)據(jù)同步的時(shí)間华畏，提高同步的效率鹏秋。
需要對源數(shù)據(jù)比如MySQL進(jìn)行切分，多線程并發(fā)讀源數(shù)據(jù)亡笑，多線程并發(fā)批量寫入分布式數(shù)據(jù)庫比如HBase,利用channel作為讀寫之間的緩沖侣夷，實(shí)現(xiàn)更好的解耦，channel可以基于文件存儲或者內(nèi)存仑乌。參見下圖：
對于源數(shù)據(jù)的切分百拓，如果是文件可以根據(jù)文件名稱設(shè)置塊大小來切分。
對于關(guān)系型數(shù)據(jù)庫晰甚，由于一般的需求是只離線同步一段時(shí)間的數(shù)據(jù)(比如凌晨把當(dāng)天的訂單數(shù)據(jù)同步到HBase)衙传，所以需要在數(shù)據(jù)切分時(shí)(按照行數(shù)切分)，會多線程掃描整個表(及時(shí)建索引厕九，也要回表)蓖捶，對于表中包含大量的數(shù)據(jù)來講，IO很高扁远，效率非常低俊鱼；這里解決的方法是對數(shù)據(jù)庫按照時(shí)間字段(按照時(shí)間同步的)建立分區(qū)刻像，每次按照分區(qū)進(jìn)行導(dǎo)出。
從傳統(tǒng)的基于關(guān)系型數(shù)據(jù)庫并行處理集群并闲、用于內(nèi)存計(jì)算近實(shí)時(shí)的细睡，到目前的基于hadoop的海量數(shù)據(jù)的分析，數(shù)據(jù)的分析在大型電子商務(wù)網(wǎng)站中應(yīng)用非常廣泛帝火，包括流量統(tǒng)計(jì)纹冤、推薦引擎、趨勢分析购公、用戶行為分析、數(shù)據(jù)挖掘分類器雁歌、分布式索引等等宏浩。
并行處理集群有商業(yè)的EMC?Greenplum，Greenplum的架構(gòu)采用了MPP(大規(guī)模并行處理)靠瞎，基于postgresql的大數(shù)據(jù)量存儲的分布式數(shù)據(jù)庫比庄。
內(nèi)存計(jì)算方面有SAP的HANA，開源的nosql內(nèi)存型的數(shù)據(jù)庫mongodb也支持mapreduce進(jìn)行數(shù)據(jù)的分析乏盐。
海量數(shù)據(jù)的離線分析目前互聯(lián)網(wǎng)公司大量的使用Hadoop佳窑，Hadoop在可伸縮性、健壯性父能、計(jì)算性能和成本上具有無可替代的優(yōu)勢神凑，事實(shí)上已成為當(dāng)前互聯(lián)網(wǎng)企業(yè)主流的大數(shù)據(jù)分析平臺
Hadoop通過MapReuce的分布式處理框架，用于處理大規(guī)模的數(shù)據(jù)何吝，伸縮性也非常好溉委；但是MapReduce最大的不足是不能滿足實(shí)時(shí)性的場景，主要用于離線的分析爱榕。
基于MapRduce模型編程做數(shù)據(jù)的分析瓣喊，開發(fā)上效率不高，位于hadoop之上Hive的出現(xiàn)使得數(shù)據(jù)的分析可以類似編寫sql的方式進(jìn)行黔酥，sql經(jīng)過語法分析藻三、生成執(zhí)行計(jì)劃后最終生成MapReduce任務(wù)進(jìn)行執(zhí)行，這樣大大提高了開發(fā)的效率跪者，做到以ad-hoc(計(jì)算在query發(fā)生時(shí))方式進(jìn)行的分析棵帽。
基于MapReduce模型的分布式數(shù)據(jù)的分析都是離線的分析，執(zhí)行上都是暴力掃描坑夯，無法利用類似索引的機(jī)制岖寞；開源的Cloudera?Impala是基于MPP的并行編程模型的，底層是Hadoop存儲的高性能的實(shí)時(shí)分析平臺柜蜈，可以大大降低數(shù)據(jù)分析的延遲仗谆。
目前Hadoop使用的版本是Hadoop1.0指巡，一方面原有的MapReduce框架存在JobTracker單點(diǎn)的問題，另外一方面JobTracker在做資源管理的同時(shí)又做任務(wù)的調(diào)度工作隶垮，隨著數(shù)據(jù)量的增大和Job任務(wù)的增多藻雪，明顯存在可擴(kuò)展性、內(nèi)存消耗狸吞、線程模型勉耀、可靠性和性能上的缺陷瓶頸；Hadoop2.0?yarn對整個框架進(jìn)行了重構(gòu)蹋偏，分離了資源管理和任務(wù)調(diào)度便斥，從架構(gòu)設(shè)計(jì)上解決了這個問題。
參考Yarn的架構(gòu)
在互聯(lián)網(wǎng)領(lǐng)域威始，實(shí)時(shí)計(jì)算被廣泛實(shí)時(shí)監(jiān)控分析枢纠、流控、風(fēng)險(xiǎn)控制等領(lǐng)域黎棠。電商平臺系統(tǒng)或者應(yīng)用對日常產(chǎn)生的大量日志和異常信息晋渺，需要經(jīng)過實(shí)時(shí)過濾、分析脓斩，以判定是否需要預(yù)警木西；
同時(shí)需要對系統(tǒng)做自我保護(hù)機(jī)制，比如對模塊做流量的控制随静，以防止非預(yù)期的對系統(tǒng)壓力過大而引起的系統(tǒng)癱瘓八千，流量過大時(shí)，可以采取拒絕或者引流等機(jī)制挪挤；有些業(yè)務(wù)需要進(jìn)行風(fēng)險(xiǎn)的控制叼丑，比如彩票中有些業(yè)務(wù)需要根據(jù)系統(tǒng)的實(shí)時(shí)銷售情況進(jìn)行限號與放號。
原始基于單節(jié)點(diǎn)的計(jì)算扛门，隨著系統(tǒng)信息量爆炸式產(chǎn)生以及計(jì)算的復(fù)雜度的增加鸠信，單個節(jié)點(diǎn)的計(jì)算已不能滿足實(shí)時(shí)計(jì)算的要求，需要進(jìn)行多節(jié)點(diǎn)的分布式的計(jì)算论寨，分布式實(shí)時(shí)計(jì)算平臺就出現(xiàn)了星立。
這里所說的實(shí)時(shí)計(jì)算，其實(shí)是流式計(jì)算葬凳，概念前身其實(shí)是CEP復(fù)雜事件處理绰垂，相關(guān)的開源產(chǎn)品如Esper，業(yè)界分布式的流計(jì)算產(chǎn)品Yahoo?S4,Twitter?storm等火焰，以storm開源產(chǎn)品使用最為廣泛劲装。
對于實(shí)時(shí)計(jì)算平臺，從架構(gòu)設(shè)計(jì)上需要考慮以下幾個因素：
1、?伸縮性
隨著業(yè)務(wù)量的增加占业，計(jì)算量的增加绒怨，通過增加節(jié)點(diǎn)處理，就可以處理谦疾。
2南蹂、?高性能、低延遲
從數(shù)據(jù)流入計(jì)算平臺數(shù)據(jù)念恍，到計(jì)算輸出結(jié)果六剥，需要性能高效且低延遲，保證消息得到快速的處理峰伙，做到實(shí)時(shí)計(jì)算疗疟。
3、?可靠性
保證每個數(shù)據(jù)消息得到一次完整處理瞳氓。
4秃嗜、?容錯性
系統(tǒng)可以自動管理節(jié)點(diǎn)的宕機(jī)失效，對應(yīng)用來說顿膨，是透明的。
Twitter的Storm在以上這幾個方面做的比較好叽赊，下面簡介一下Storm的架構(gòu)恋沃。
整個集群的管理是通過zookeeper來進(jìn)行的。
客戶端提交拓?fù)涞絥imbus必指。
Nimbus針對該拓?fù)浣⒈镜氐哪夸浉鶕?jù)topology的配置計(jì)算task囊咏，分配task，在zookeeper上建立assignments節(jié)點(diǎn)存儲task和supervisor機(jī)器節(jié)點(diǎn)中woker的對應(yīng)關(guān)系塔橡。
在zookeeper上創(chuàng)建taskbeats節(jié)點(diǎn)來監(jiān)控task的心跳梅割；啟動topology。
Supervisor去zookeeper上獲取分配的tasks葛家，啟動多個woker進(jìn)行户辞，每個woker生成task，一個task一個線程癞谒；根據(jù)topology信息初始化建立task之間的連接;Task和Task之間是通過zeroMQ管理的底燎；之后整個拓?fù)溥\(yùn)行起來。
Tuple是流的基本處理單元弹砚，也就是一個消息双仍，Tuple在task中流轉(zhuǎn)，Tuple的發(fā)送和接收過程如下：
發(fā)送Tuple桌吃，Worker提供了一個transfer的功能朱沃，用于當(dāng)前task把tuple發(fā)到到其他的task中。以目的taskid和tuple參數(shù)，序列化tuple數(shù)據(jù)并放到transfer?queue中逗物。
在0.8版本之前搬卒，這個queue是LinkedBlockingQueue，0.8之后是DisruptorQueue敬察。
在0.8版本之后秀睛，每一個woker綁定一個inbound?transfer?queue和outbond?queue，inbound?queue用于接收message莲祸，outbond?queue用于發(fā)送消息蹂安。
發(fā)送消息時(shí)，由單個線程從transferqueue中拉取數(shù)據(jù)锐帜，把這個tuple通過zeroMQ發(fā)送到其他的woker中田盈。
接收Tuple，每個woker都會監(jiān)聽zeroMQ的tcp端口來接收消息缴阎，消息放到DisruptorQueue中后允瞧，后從queue中獲取message(taskid,tuple)，根據(jù)目的taskid,tuple的值路由到task中執(zhí)行蛮拔。每個tuple可以emit到direct?steam中述暂，也可以發(fā)送到regular?stream中，在Reglular方式下建炫，由Stream?Group（stream?id-->component?id?-->outbond?tasks）功能完成當(dāng)前tuple將要發(fā)送的Tuple的目的地畦韭。
通過以上分析可以看到，Storm在伸縮性肛跌、容錯性艺配、高性能方面的從架構(gòu)設(shè)計(jì)的角度得以支撐；同時(shí)在可靠性方面衍慎，Storm的ack組件利用異或xor算法在不失性能的同時(shí)转唉，保證每一個消息得到完整處理的同時(shí)。
實(shí)時(shí)推送的應(yīng)用場景非常多稳捆，比如系統(tǒng)的監(jiān)控動態(tài)的實(shí)時(shí)曲線繪制赠法，手機(jī)消息的推送，web實(shí)時(shí)聊天等乔夯。
實(shí)時(shí)推送有很多技術(shù)可以實(shí)現(xiàn)期虾，有Comet方式，有websocket方式等驯嘱。
Comet基于服務(wù)器長連接的“服務(wù)器推”技術(shù)镶苞，包含兩種：
Long?Polling：服務(wù)器端在接到請求后掛起，有更新時(shí)返回連接即斷掉鞠评，然后客戶端再發(fā)起新的連接
Stream方式:每次服務(wù)端數(shù)據(jù)傳送不會關(guān)閉連接茂蚓，連接只會在通信出現(xiàn)錯誤時(shí)，或是連接重建時(shí)關(guān)閉（一些防火墻常被設(shè)置為丟棄過長的連接，?服務(wù)器端可以設(shè)置一個超時(shí)時(shí)間聋涨，?超時(shí)后通知客戶端重新建立連接晾浴，并關(guān)閉原來的連接）。
Websocket：長連接牍白，全雙工通信
是HTML5的一種新的協(xié)議脊凰。它實(shí)現(xiàn)了瀏覽器與服務(wù)器的雙向通訊。webSocket?API中茂腥，瀏覽器和服務(wù)器端只需要通過一個握手的動作狸涌，便能形成瀏覽器與客戶端之間的快速雙向通道，使得數(shù)據(jù)可以快速的雙向傳播最岗。
Socket.io是一個NodeJS?websocket庫帕胆，包括客戶端的JS和服務(wù)端的的nodejs，用于快速構(gòu)建實(shí)時(shí)的web應(yīng)用般渡。
待補(bǔ)充
數(shù)據(jù)庫存儲大體分為以下幾類懒豹，有關(guān)系型（事務(wù)型）的數(shù)據(jù)庫，以oracle驯用、mysql為代表脸秽，有keyvalue數(shù)據(jù)庫，以redis和memcached?db為代表蝴乔，有文檔型數(shù)據(jù)庫如mongodb豹储，有列式分布式數(shù)據(jù)庫以HBase，cassandra,dynamo為代表淘这，還有其他的圖形數(shù)據(jù)庫、對象數(shù)據(jù)?庫巩剖、xml數(shù)據(jù)庫等铝穷。每種類型的數(shù)據(jù)庫應(yīng)用的業(yè)務(wù)領(lǐng)域是不一樣的，下面從內(nèi)存型佳魔、關(guān)系型曙聂、分布式三個維度針對相關(guān)的產(chǎn)品做性能可用性等方面的考量分析。
內(nèi)存型的數(shù)據(jù)庫鞠鲜，以高并發(fā)高性能為目標(biāo)宁脊，在事務(wù)性方面沒那么嚴(yán)格，以開源nosql數(shù)據(jù)庫mongodb贤姆、redis為例
??Mongodb
通信方式
多線程方式榆苞，主線程監(jiān)聽新的連接，連接后霞捡，啟動新的線程做數(shù)據(jù)的操作（IO切換）坐漏。
數(shù)據(jù)結(jié)構(gòu)
數(shù)據(jù)庫-->collection-->record
MongoDB在數(shù)據(jù)存儲上按命名空間來劃分，一個collection是一個命名空間，一個索引也是一個命名空間赊琳。
同一個命名空間的數(shù)據(jù)被分成很多個Extent街夭，Extent之間使用雙向鏈表連接。
在每一個Extent中躏筏，保存了具體每一行的數(shù)據(jù)板丽，這些數(shù)據(jù)也是通過雙向鏈接連接的。
每一行數(shù)據(jù)存儲空間不僅包括數(shù)據(jù)占用空間趁尼，還可能包含一部分附加空間埃碱，這使得在數(shù)據(jù)update變大后可以不移動位置。
索引以BTree結(jié)構(gòu)實(shí)現(xiàn)弱卡。
如果你開啟了jorunaling日志乃正，那么還會有一些文件存儲著你所有的操作記錄。
持久化存儲
MMap方式把文件地址映射到內(nèi)存的地址空間婶博，直接操作內(nèi)存地址空間就可以操作文件瓮具，不用再調(diào)用write,read操作，性能比較高凡人。
mongodb調(diào)用mmap把磁盤中的數(shù)據(jù)映射到內(nèi)存中的名党，所以必須有一個機(jī)制時(shí)刻的刷數(shù)據(jù)到硬盤才能保證可靠性，多久刷一次是與syncdelay參數(shù)相關(guān)的挠轴。
journal（進(jìn)行恢復(fù)用）是Mongodb中的redo?log传睹，而Oplog則是負(fù)責(zé)復(fù)制的binlog岸晦。如果打開journal，那么即使斷電也只會丟失100ms的數(shù)據(jù)邢隧，這對大多數(shù)應(yīng)用來說都可以容忍了。從1.9.2+倒慧，mongodb都會默認(rèn)打開journal功能包券，以確保數(shù)據(jù)安全纫谅。而且journal的刷新時(shí)間是可以改變的溅固，2-300ms的范圍,使用--journalCommitInterval命令。Oplog和數(shù)據(jù)刷新到磁盤的時(shí)間是60s盹牧，對于復(fù)制來說汰寓，不用等到oplog刷新磁盤有滑，在內(nèi)存中就可以直接復(fù)制到Sencondary節(jié)點(diǎn)。
事務(wù)支持
Mongodb只支持對單行記錄的原子操作
HA集群
用的比較多的是Replica?Sets望艺，采用選舉算法找默，自動進(jìn)行l(wèi)eader選舉惩激，在保證可用性的同時(shí)风钻，可以做到強(qiáng)一致性要求骡技。
當(dāng)然對于大量的數(shù)據(jù)布朦，mongodb也提供了數(shù)據(jù)的切分架構(gòu)Sharding昼窗。
??Redis
豐富的數(shù)據(jù)結(jié)構(gòu)是趴，高速的響應(yīng)速度，內(nèi)存操作
通信方式
因都在內(nèi)存操作，所以邏輯的操作非崇拖鳎快亭敢，減少了CPU的切換開銷帅刀，所以為單線程的模式（邏輯處理線程和主線程是一個）扣溺。
reactor模式锥余，實(shí)現(xiàn)自己的多路復(fù)用NIO機(jī)制（epoll驱犹，select雄驹，kqueue等）
單線程處理多任務(wù)
數(shù)據(jù)結(jié)構(gòu)
hash+bucket結(jié)構(gòu)医舆，當(dāng)鏈表的長度過長時(shí)彬向，會采取遷移的措施（擴(kuò)展原來兩倍的hash表遍希，把數(shù)據(jù)遷移過去凿蒜，expand+rehash）
持久化存儲
a废封、全量持久化RDB（遍歷redisDB,讀取bucket中的key,value）漂洋，save命令阻塞主線程刽漂，bgsave開啟子進(jìn)程進(jìn)行snapshot持久化操作贝咙，生成rdb文件庭猩。
在shutdown時(shí)蔼水，會調(diào)用save操作
數(shù)據(jù)發(fā)生變化徙缴，在多少秒內(nèi)觸發(fā)一次bgsave
sync于样，master接受slave發(fā)出來的命令
b穿剖、增量持久化（aof類似redolog）糊余，先寫到日志buffer,再flush到日志文件中（flush的策略可以配置的贬芥，而已單條蘸劈，也可以批量）贤惯，只有flush到文件上的孵构，才真正返回客戶端颈墅。
要定時(shí)對aof文件和rdb文件做合并操作（在快照過程中恤筛，變化的數(shù)據(jù)先寫到aof?buf中等子進(jìn)程完成快照<內(nèi)存snapshot>后叹俏，再進(jìn)行合并aofbuf變化的部分以及全鏡像數(shù)據(jù)）粘驰。
在高并發(fā)訪問模式下蝌数，RDB模式使服務(wù)的性能指標(biāo)出現(xiàn)明顯的抖動，aof在性能開銷上比RDB好唆貌，但是恢復(fù)時(shí)重新加載到內(nèi)存的時(shí)間和數(shù)據(jù)量成正比锨咙。
集群HA
通用的解決方案是主從備份切換酪刀，采用HA軟件骂倘，使得失效的主redis可以快速的切換到從redis上历涝。主從數(shù)據(jù)的同步采用復(fù)制機(jī)制，該場景可以做讀寫分離电爹。
目前在復(fù)制方面丐箩，存在的一個問題是在遇到網(wǎng)絡(luò)不穩(wěn)定的情況下屎勘，Slave和Master斷開（包括閃斷）會導(dǎo)致Master需要將內(nèi)存中的數(shù)據(jù)全部重新生成rdb文件（快照文件）概漱，然后傳輸給Slave竿裂。Slave接收完Master傳遞過來的rdb文件以后會將自身的內(nèi)存清空腻异，把rdb文件重新加載到內(nèi)存中悔常。這種方式效率比較低下机打，在后面的未來版本Redis2.8作者已經(jīng)實(shí)現(xiàn)了部分復(fù)制的功能。
關(guān)系型數(shù)據(jù)庫在滿足并發(fā)性能的同時(shí)罐旗，也需要滿足事務(wù)性九秀，以mysql數(shù)據(jù)庫為例鼓蜒，講述架構(gòu)設(shè)計(jì)原理都弹，在性能方面的考慮，以及如何滿足可用性的需求框杜。
??mysql的架構(gòu)原理(innodb)
在架構(gòu)上咪辱，mysql分為server層和存儲引擎層油狂。
Server層的架構(gòu)對于不同的存儲引擎來講都是一樣的,包括連接/線程處理夹供、查詢處理(parser、optimizer)以及其他系統(tǒng)任務(wù)弦聂。存儲引擎層有很多種莺葫，mysql提供了存儲引擎的插件式結(jié)構(gòu)，支持多種存儲引擎堡纬，用的最廣泛的是innodb和myisamin烤镐；inodb主要面向OLTP方面的應(yīng)用，支持事務(wù)處理镜悉，myisam不支持事務(wù)侣肄，表鎖茫孔，對OLAP操作速度快。
以下主要針對innodb存儲引擎做相關(guān)介紹剩晴。
在線程處理方面毅整，Mysql是多線程的架構(gòu)悼嫉，由一個master線程戏蔑，一個鎖監(jiān)控線程，一個錯誤監(jiān)控線程情龄，和多個IO線程組成骤视。并且對一個連接會開啟一個線程進(jìn)行服務(wù)。io線程又分為節(jié)省隨機(jī)IO的insert?buffer笼裳，用于事務(wù)控制的類似于oracle的redo?log躬柬，以及多個write，多個read的硬盤和內(nèi)存交換的IO線程颠锉。
在內(nèi)存分配方面琼掠，包括innodb?buffer?pool悼瓮，以及l(fā)og?buffer横堡。其中innodb?buffer?pool包括insert?buffer、datapage胸蛛、index?page、數(shù)據(jù)字典肃弟、自適應(yīng)hash。Log?buffer用于緩存事務(wù)日志箩兽，提供性能。
在數(shù)據(jù)結(jié)構(gòu)方面落包，innodb包括表空間咐蝇、段、區(qū)旭寿、頁/塊，行微渠。索引結(jié)構(gòu)是B+tree結(jié)構(gòu)檀蹋，包括二級索引和主鍵索引俯逾，二級索引的葉子節(jié)點(diǎn)是主鍵PK，根據(jù)主鍵索引的葉子節(jié)點(diǎn)指向存儲的數(shù)據(jù)塊坠七。這種B+樹存儲結(jié)構(gòu)可以更好的滿足隨機(jī)查詢操作IO要求彪置，分為數(shù)據(jù)頁和二級索引頁，修改二級索引頁面涉及到隨機(jī)操作潘懊，為了提高寫入時(shí)的性能，采用insert?buffer做順序的寫入岂却，再由后臺線程以一定頻率將多個插入合并到二級索引頁面。為了保證數(shù)據(jù)庫的一致性(內(nèi)存和硬盤數(shù)據(jù)文件)扫尺，以及縮短實(shí)例恢復(fù)的時(shí)間，關(guān)系型數(shù)據(jù)庫還有一個checkpoint的功能炊汤，用于把內(nèi)存buffer中之前的臟頁按照比例(老的LSN)寫入磁盤评甜，這樣redolog文件的LSN以前的日志就可以被覆蓋了，進(jìn)行循環(huán)使用握爷；在失效恢復(fù)時(shí)襟交，只需要從日志中LSN點(diǎn)進(jìn)行恢復(fù)即可。
在事務(wù)特性支持上伤靠，關(guān)系型數(shù)據(jù)庫需要滿足ACID四個特性捣域，需要根據(jù)不同的事務(wù)并發(fā)和數(shù)據(jù)可見性要求，定義了不同的事務(wù)隔離級別宴合，并且離不開對資源爭用的鎖機(jī)制焕梅，要避免產(chǎn)生死鎖，mysql在Server層和存儲引擎層做并發(fā)控制卦洽，主要體現(xiàn)在讀寫鎖贞言，根據(jù)鎖粒度不同，有各個級別的鎖(表鎖阀蒂、行鎖该窗、頁鎖、MVCC)脂新；基于提高并發(fā)性能的考慮挪捕，使用多版本并發(fā)控制MVCC來支持事務(wù)的隔離粗梭，并基于undo來實(shí)現(xiàn)争便，在做事務(wù)回滾時(shí)，也會用到undo段断医。mysql用redolog來保證數(shù)據(jù)的寫入的性能和失效恢復(fù)滞乙，在修改數(shù)據(jù)時(shí)只需要修改內(nèi)存，再把修改行為記錄到事務(wù)日志中(順序IO)鉴嗤，不用每次將數(shù)據(jù)修改本身持久化到硬盤(隨機(jī)IO)斩启，大大提高性能。
在可靠性方面醉锅，innodb存儲引擎提供了兩次寫機(jī)制double?writer用于防止在flush頁面到存儲上出現(xiàn)的錯誤兔簇，解決磁盤half-writern的問題。
??對于高并發(fā)高性能的mysql來講硬耍，可以在多個維度進(jìn)行性能方面的調(diào)優(yōu)垄琐。
a、硬件級別经柴，
日志和數(shù)據(jù)的存儲狸窘，需要分開，日志是順序的寫坯认，需要做raid1+0翻擒，并且用buffer-IO氓涣；數(shù)據(jù)是離散的讀寫，走direct?IO即可陋气，避免走文件系統(tǒng)cache帶來的開銷劳吠。
存儲能力，SAS盤raid操作（raid卡緩存恩伺，關(guān)閉讀cache赴背，關(guān)閉磁盤cache，關(guān)閉預(yù)讀晶渠，只用writeback?buffer凰荚，不過需要考慮充放電的問題），當(dāng)然如果數(shù)據(jù)規(guī)模不大褒脯，數(shù)據(jù)的存儲可以用高速的設(shè)備便瑟，F(xiàn)usion?IO、SSD番川。
對于數(shù)據(jù)的寫入到涂，控制臟頁刷新的頻率，對于數(shù)據(jù)的讀取颁督，控制cache?hit率践啄；因此而估算系統(tǒng)需要的IOPS，評估需要的硬盤數(shù)量(fusion?io上到IOPS在10w以上沉御，普通的硬盤150)屿讽。
Cpu方面，單實(shí)例關(guān)閉NUMA吠裆，mysql對多核的支持不是太好伐谈，可以對多實(shí)例進(jìn)行CPU綁定。
b试疙、操作系統(tǒng)級別诵棵，
內(nèi)核以及socket的優(yōu)化，網(wǎng)絡(luò)優(yōu)化bond祝旷、文件系統(tǒng)履澳、IO調(diào)度
innodb主要用在OLTP類應(yīng)用，一般都是IO密集型的應(yīng)用怀跛，在提高IO能力的基礎(chǔ)上距贷，充分利用cache機(jī)制。需要考慮的內(nèi)容有敌完，
在保證系統(tǒng)可用內(nèi)存的基礎(chǔ)上储耐，盡可能的擴(kuò)大innodb?buffer?pool，一般設(shè)置為物理內(nèi)存的3/4
文件系統(tǒng)的使用滨溉，只在記錄事務(wù)日志的時(shí)候用文件系統(tǒng)的cache什湘；盡量避免mysql用到swap(可以將vm.swappiness=0长赞，內(nèi)存緊張時(shí)，釋放文件系統(tǒng)cache)
IO調(diào)度優(yōu)化闽撤，減少不必要的阻塞得哆，降低隨機(jī)IO訪問的延時(shí)(CFQ、Deadline哟旗、NOOP)
c贩据、server以及存儲引擎級別（連接管理、網(wǎng)絡(luò)管理闸餐、table管理饱亮、日志）
包括cache/buffer、Connection舍沙、IO
d近上、應(yīng)用級別（比如索引的考慮，schema的優(yōu)化適當(dāng)冗余拂铡；優(yōu)化sql查詢導(dǎo)致的CPU問題和內(nèi)存問題壹无，減少鎖的范圍，減少回表掃描感帅，覆蓋索引）
??在高可用實(shí)踐方面斗锭，
支持master-master、master-slave模式失球，master-master模式是一個作為主負(fù)責(zé)讀寫岖是，另外一個作為standby提供災(zāi)備，maser-slave是一個作為主提供寫操作她倘，其他幾個節(jié)點(diǎn)作為讀操作璧微，支持讀寫分離作箍。
對于節(jié)點(diǎn)主備失效檢測和切換硬梁，可以采用HA軟件，當(dāng)然也可以從更細(xì)粒度定制的角度胞得，采用zookeeper作為集群的協(xié)調(diào)服務(wù)荧止。
對于分布式的系統(tǒng)來講，數(shù)據(jù)庫主備切換的一致性始終是一個問題阶剑，可以有以下幾種方式：
a跃巡、集群方式，如oracle的rack牧愁，缺點(diǎn)是比較復(fù)雜
b素邪、共享SAN存儲方式，相關(guān)的數(shù)據(jù)文件和日志文件都放在共享存儲上猪半，優(yōu)點(diǎn)是主備切換時(shí)數(shù)據(jù)保持一致兔朦，不會丟失偷线，但由于備機(jī)有一段時(shí)間的拉起，會有短暫的不可用狀態(tài)
c沽甥、主備進(jìn)行數(shù)據(jù)同步的方式声邦，常見的是日志的同步，可以保障熱備摆舟，實(shí)時(shí)性好亥曹，但是切換時(shí)，可能有部分?jǐn)?shù)據(jù)沒有同步過來恨诱，帶來了數(shù)據(jù)的一致性問題媳瞪。可以在操作主數(shù)據(jù)庫的同時(shí)照宝，記錄操作日志材失，切換到備時(shí)，會和操作日志做個check硫豆，補(bǔ)齊未同步過來的數(shù)據(jù)龙巨；
d、還有一種做法是備庫切換到主庫的regolog的存儲上熊响，保證數(shù)據(jù)不丟失旨别。
數(shù)據(jù)庫主從復(fù)制的效率在mysql上不是太高，主要原因是事務(wù)是嚴(yán)格保持順序的汗茄，索引mysql在復(fù)制方面包括日志IO和relog?log兩個過程都是單線程的串行操作秸弛，在數(shù)據(jù)復(fù)制優(yōu)化方面，盡量減少IO的影響洪碳。不過到了Mysql5.6版本递览，可以支持在不同的庫上的并行復(fù)制。
??基于不同業(yè)務(wù)要求的存取方式
平臺業(yè)務(wù)中瞳腌，不同的業(yè)務(wù)有不同的存取要求绞铃，比如典型的兩大業(yè)務(wù)用戶和訂單，用戶一般來講總量是可控的嫂侍，而訂單是不斷地遞增的儿捧，對于用戶表首先采取分庫切分，每個sharding做一主多讀挑宠，同樣對于訂單因更多需求的是用戶查詢自己的訂單菲盾，也需要按照用戶進(jìn)行切分訂單庫，并且支持一主多讀各淀。
在硬件存儲方面懒鉴，對于事務(wù)日志因是順序?qū)懀W存的優(yōu)勢比硬盤高不了多少碎浇，所以采取電池保護(hù)的寫緩存的raid卡存儲临谱；對于數(shù)據(jù)文件咆畏，無論是對用戶或者訂單都會存在大量的隨機(jī)讀寫操作，當(dāng)然加大內(nèi)存是一個方面吴裤，另外可以采用高速的IO設(shè)備閃存旧找，比如PCIe卡fusion-io。使用閃存也適合在單線程的負(fù)載中麦牺，比如主從復(fù)制钮蛛，可以對從節(jié)點(diǎn)配置fusion-IO卡，降低復(fù)制的延遲剖膳。
對于訂單業(yè)務(wù)來講魏颓，量是不斷遞增的，PCIe卡存儲容量比較有限吱晒，并且訂單業(yè)務(wù)的熱數(shù)據(jù)只有最近一段時(shí)間的(比如近3個月的)甸饱，對此這里列兩種解決方案，一種是flashcache方式仑濒，采用基于閃存和硬盤存儲的開源混合存儲方式叹话，在閃存中存儲熱點(diǎn)的數(shù)據(jù)。另外一種是可以定期把老的數(shù)據(jù)導(dǎo)出到分布式數(shù)據(jù)庫HBase中墩瞳，用戶在查詢訂單列表是近期的數(shù)據(jù)從mysql中獲取驼壶，老的數(shù)據(jù)可以從HBase中查詢，當(dāng)然需要HBase良好的rowkey設(shè)計(jì)以適應(yīng)查詢需求喉酌。
對于數(shù)據(jù)的高并發(fā)的訪問热凹，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫提供讀寫分離的方案，但是帶來的確實(shí)數(shù)據(jù)的一致性問題提供的數(shù)據(jù)切分的方案泪电；對于越來越多的海量數(shù)據(jù)般妙，傳統(tǒng)的數(shù)據(jù)庫采用的是分庫分表，實(shí)現(xiàn)起來比較復(fù)雜相速，后期要不斷的進(jìn)行遷移維護(hù)碟渺；對于高可用和伸縮方面，傳統(tǒng)數(shù)據(jù)采用的是主備和蚪、主從止状、多主的方案烹棉，但是本身擴(kuò)展性比較差攒霹，增加節(jié)點(diǎn)和宕機(jī)需要進(jìn)行數(shù)據(jù)的遷移。對于以上提出的這些問題浆洗，分布式數(shù)據(jù)庫HBase有一套完善的解決方案催束，適用于高并發(fā)海量數(shù)據(jù)存取的要求。
??HBase
基于列式的高效存儲降低IO
通常的查詢不需要一行的全部字段伏社，大多數(shù)只需要幾個字段
對與面向行的存儲系統(tǒng)抠刺，每次查詢都會全部數(shù)據(jù)取出塔淤，然后再從中選出需要的字段
面向列的存儲系統(tǒng)可以單獨(dú)查詢某一列，從而大大降低IO
提高壓縮效率
同列數(shù)據(jù)具有很高的相似性速妖，會增加壓縮效率
Hbase的很多特性高蜂，都是由列存儲決定的
高性能
LSM?Tree
適合高速寫的場景
強(qiáng)一致的數(shù)據(jù)訪問
MVCC
HBase的一致性數(shù)據(jù)訪問是通過MVCC來實(shí)現(xiàn)的。
HBase在寫數(shù)據(jù)的過程中罕容，需要經(jīng)過好幾個階段备恤，寫HLog，寫memstore锦秒，更新MVCC;
只有更新了MVCC露泊，才算真正memstore寫成功，其中事務(wù)的隔離需要有mvcc的來控制旅择，比如讀數(shù)據(jù)不可以獲取別的線程還未提交的數(shù)據(jù)惭笑。
高可靠
HBase的數(shù)據(jù)存儲基于HDFS，提供了冗余機(jī)制生真。
Region節(jié)點(diǎn)的宕機(jī)沉噩，對于內(nèi)存中的數(shù)據(jù)還未flush到文件中，提供了可靠的恢復(fù)機(jī)制柱蟀。
可伸縮屁擅，自動切分，遷移
通過Zookeeper定位目標(biāo)Region?Server产弹，最后定位Region派歌。
Region?Server擴(kuò)容，通過將自身發(fā)布到Master痰哨，Master均勻分布胶果。
可用性
存在單點(diǎn)故障，Region?Server宕機(jī)后斤斧，短時(shí)間內(nèi)該server維護(hù)的region無法訪問早抠，等待failover生效。
通過Master維護(hù)各Region?Server健康狀況和Region分布撬讽。
多個Master蕊连，Master宕機(jī)有zookeeper的paxos投票機(jī)制選取下一任Master。Master就算全宕機(jī)游昼，也不影響Region讀寫甘苍。Master僅充當(dāng)一個自動運(yùn)維角色。
HDFS為分布式存儲引擎烘豌，一備三载庭，高可靠，0數(shù)據(jù)丟失。
HDFS的namenode是一個SPOF囚聚。
為避免單個region訪問過于頻繁靖榕，單機(jī)壓力過大，提供了split機(jī)制
HBase的寫入是LSM-TREE的架構(gòu)方式顽铸，隨著數(shù)據(jù)的append茁计，HFile越來越多，HBase提供了HFile文件進(jìn)行compact谓松，對過期數(shù)據(jù)進(jìn)行清除簸淀，提高查詢的性能。
Schema?free
HBase沒有像關(guān)系型數(shù)據(jù)庫那樣的嚴(yán)格的schema毒返，可以自由的增加和刪除schema中的字段租幕。
HBase分布式數(shù)據(jù)庫，對于二級索引支持的不太好拧簸，目前只支持在rowkey上的索引劲绪，所以rowkey的設(shè)計(jì)對于查詢的性能來講非常關(guān)鍵。
統(tǒng)一的配置庫
部署平臺
大型分布式系統(tǒng)涉及各種設(shè)備贾富，比如網(wǎng)絡(luò)交換機(jī)，普通PC機(jī)牺六，各種型號的網(wǎng)卡颤枪，硬盤，內(nèi)存等等淑际，還有應(yīng)用業(yè)務(wù)層次的監(jiān)控畏纲，數(shù)量非常多的時(shí)候，出現(xiàn)錯誤的概率也會變大春缕，并且有些監(jiān)控的時(shí)效性要求比較高盗胀，有些達(dá)到秒級別；在大量的數(shù)據(jù)流中需要過濾異常的數(shù)據(jù)锄贼，有時(shí)候也對數(shù)據(jù)會進(jìn)行上下文相關(guān)的復(fù)雜計(jì)算票灰，進(jìn)而決定是否需要告警。因此監(jiān)控平臺的性能宅荤、吞吐量屑迂、已經(jīng)可用性就比較重要，需要規(guī)劃統(tǒng)一的一體化的監(jiān)控平臺對系統(tǒng)進(jìn)行各個層次的監(jiān)控冯键。
平臺的數(shù)據(jù)分類
應(yīng)用業(yè)務(wù)級別：應(yīng)用事件惹盼、業(yè)務(wù)日志、審計(jì)日志琼了、請求日志逻锐、異常夫晌、請求業(yè)務(wù)metrics雕薪、性能度量
系統(tǒng)級別：CPU昧诱、內(nèi)存、網(wǎng)絡(luò)所袁、IO
時(shí)效性要求
閥值盏档，告警：
實(shí)時(shí)計(jì)算：
近實(shí)時(shí)分鐘計(jì)算
按小時(shí)、天的離線分析
實(shí)時(shí)查詢
架構(gòu)
節(jié)點(diǎn)中Agent代理可以接收日志燥爷、應(yīng)用的事件以及通過探針的方式采集數(shù)據(jù)蜈亩，agent采集數(shù)據(jù)的一個原則是和業(yè)務(wù)應(yīng)用的流程是異步隔離的，不影響交易流程前翎。
數(shù)據(jù)統(tǒng)一通過collector集群進(jìn)行收集稚配，按照數(shù)據(jù)的不同類型分發(fā)到不同的計(jì)算集群進(jìn)行處理；有些數(shù)據(jù)時(shí)效性不是那么高港华，比如按小時(shí)進(jìn)行統(tǒng)計(jì)道川，放入hadoop集群；有些數(shù)據(jù)是請求流轉(zhuǎn)的跟蹤數(shù)據(jù)立宜，需要可以查詢的冒萄，那么就可以放入solr集群進(jìn)行索引；有些數(shù)據(jù)需要進(jìn)行實(shí)時(shí)計(jì)算的進(jìn)而告警的橙数，需要放到storm集群中進(jìn)行處理尊流。
數(shù)據(jù)經(jīng)過計(jì)算集群處理后，結(jié)果存儲到Mysql或者HBase中灯帮。
監(jiān)控的web應(yīng)用可以把監(jiān)控的實(shí)時(shí)結(jié)果推送到瀏覽器中崖技，也可以提供API供結(jié)果的展現(xiàn)和搜索。
