專業(yè)技能

1.分布式服務(wù)

• 為什么要做分布式服務(wù)
  首先分析之前的系統(tǒng)架構(gòu)及其存在的問題：單一系統(tǒng)在大容量、高并發(fā)、業(yè)務(wù)耦合、業(yè)務(wù)快速發(fā)展、系統(tǒng)演進(jìn)迭代方面存在問題
• 分布式服務(wù)應(yīng)該怎么做
  1.原則：
  無狀態(tài)化（即使有，也要將狀態(tài)封裝在小范圍內(nèi)，避免影響橫向擴(kuò)展）
  2.向2個方向擴(kuò)展：
  橫向和縱向。橫向解決系統(tǒng)的容量問題，同時對業(yè)務(wù)系統(tǒng)的拆分又能是業(yè)務(wù)領(lǐng)域知識專門化，有利于系統(tǒng)穩(wěn)定性?？v向解決系統(tǒng)的靈活性和復(fù)雜性。同時業(yè)務(wù)進(jìn)行縱向拆分，能夠解決業(yè)務(wù)的邏輯復(fù)雜性，支持業(yè)務(wù)的快速擴(kuò)展。
  3.要有相關(guān)的支撐體系
  分布式配置中心、分布式消息系統(tǒng)、分布式緩存、分布式數(shù)據(jù)存儲
  4.解決分布式的典型問題
  通過以上的支撐體系，來解決典型問題，如 集群管理、共享鎖、隊列管理等問題
  5.典型的分布式集群的設(shè)計思路
  master-slave模式：如主從復(fù)制，雙主+主從。示例：tair 如何解決擴(kuò)容和數(shù)據(jù)一致性的。（擴(kuò)容通過bucket的轉(zhuǎn)移，容災(zāi)通過bucket的副本機(jī)制和配置更新時的版本控制）
  無對等設(shè)計：利用gossip協(xié)議。（謠言協(xié)議，形象點說就是：說的人多了，就成了真的了。。。）

2.分布式緩存

• 了解哪些
  使用過的有tair和redis，對redis了解的多一些
• redis都有哪些了解
  1.數(shù)據(jù)結(jié)構(gòu)，典型的如skiplist
  2.線程模型：
  單線程。風(fēng)險點：大數(shù)據(jù)的操作容易造成阻塞
  3.持久化
  RDB。風(fēng)險點：save會阻塞服務(wù)，bgsave不會阻塞服務(wù)（用的子進(jìn)程+寫時復(fù)制）。
  AOF。記錄命令的方式?？蛇M(jìn)行重寫來縮減體積。
  4.集群故障發(fā)現(xiàn)
  gossip協(xié)議。多數(shù)人說某臺機(jī)器有問題，就是有問題，就下掉該master
  5.故障轉(zhuǎn)移
  epoch機(jī)制。slave發(fā)起選舉，每輪epoch只能投一票。投不出結(jié)果就再來一輪epoch
  6.緩存雪崩
  避免同時過期、雙緩存機(jī)制
  7.緩存穿透
  穿透后加互斥鎖再訪問數(shù)據(jù)庫、布隆過濾器來判斷是否是正常請求。
  8.集群復(fù)制 TODO
  hash槽，moved，ask
  9.大key
  對于集合類型的，拆分成多個key；禁止批量獲取1000個以上的key
  10.熱點key
  key分段+multi get、key做多個副本（針對小容量key）、服務(wù)本地緩存
  11.線上問題
  大key，熱點key
• 優(yōu)勢劣勢
  1.優(yōu)勢 純內(nèi)存速度快，數(shù)據(jù)結(jié)構(gòu)支持應(yīng)用場景多、
  2.劣勢 容量小

3.分布式任務(wù)

• 分布式調(diào)度
  1.任務(wù)分發(fā)模式。由任務(wù)自己控制源數(shù)據(jù)的獲取。優(yōu)點是并行度高。
  2.數(shù)據(jù)分發(fā)模式。任務(wù)系統(tǒng)抽取源數(shù)據(jù)，分發(fā)到任務(wù)。

• 任務(wù)設(shè)計
  1.規(guī)范
  6個階段：任務(wù)配置、任務(wù)執(zhí)行、結(jié)果通知、業(yè)務(wù)監(jiān)控、異常掛牌、異常重跑
  3個級別：強(qiáng)制、推薦、參考
  21子項：
  任務(wù)配置：執(zhí)行時間窗口、執(zhí)行時長、任務(wù)依賴
  任務(wù)執(zhí)行：依賴校驗、異常隔離、接口重試、可終止。。
  異常重跑：

• 為什么用java任務(wù)，而不用大數(shù)據(jù)處理
  1.復(fù)雜性。業(yè)務(wù)邏輯復(fù)雜，很難處理。
  2.成本。比如依賴各方的服務(wù)，而數(shù)據(jù)層是業(yè)務(wù)隔離的，但是java服務(wù)接口是現(xiàn)成的。
  3.效率。
  4.質(zhì)量。

• 高并發(fā)
  多機(jī)分片+多線程、控制數(shù)據(jù)庫寫入速率防止主從延遲、外部輸入數(shù)據(jù)查詢?nèi)绻胁樵兲紤]分片并行查詢、任務(wù)結(jié)果同步到緩存

• 數(shù)據(jù)一致性
  數(shù)據(jù)源的flag校驗、對賬、冪等、重跑修復(fù)、異常重試、異常監(jiān)控

• 分布式
  任務(wù)防并發(fā)執(zhí)行（考勤）、分布式調(diào)度分片

4. MQ

• 介紹
  特性：分布式的（topic分區(qū)且副本機(jī)制），pull模型（消費者維護(hù)消費進(jìn)度，可回溯），分區(qū)內(nèi)的有序性，無中心的控制機(jī)制（zk選舉controller，進(jìn)行集群管理，如分片）。

• 集群

• 數(shù)據(jù)一致性
  多種ack模式

• 消息順序性
  offset機(jī)制。每條生產(chǎn)的消息都會被分配一個offset，其在分區(qū)內(nèi)是唯一的，順序的。offset不會跨越分區(qū)。所以消費者通過記錄offset并順序消費消息，來達(dá)到消息順序性

• 日志壓縮
  首先，在特定場景中，消費者只關(guān)心key對應(yīng)的最新value。所以kafka啟動子線程壓縮日志，只保留最新的value

• ISR
  同步的副本的集合。由leader副本維護(hù)。如果同步的消息滯后，就會被剔除。被剔除的不能被選擇為leader。

• 定期刪除舊消息的策略
  1.根據(jù)消息的保留時間 2.topic下消息的大小

• 高并發(fā)

  1. topic分區(qū)。主副本負(fù)責(zé)讀寫，flower副本只負(fù)責(zé)同步容災(zāi)。
     2.批量發(fā)送
     3.數(shù)據(jù)存儲，不在cache中，而是落入磁盤，且利用了順序?qū)懭氲母咝阅?br> 4.IO：zero-copy

• 高可用
  分布式集群

• 負(fù)載均衡
  1.生產(chǎn)者通過指定算法發(fā)送到不同分區(qū)
  2.不同分區(qū)在不同broker上有副本。主副本負(fù)責(zé)讀寫
  3.zk負(fù)責(zé)信息維護(hù)和更新

• 為什么用（優(yōu)點）

• 缺點是什么

5. thrift