1、分佈式系統是用來解決集中式架構的性能瓶頸問題，其核心是可擴展性，其特點包括：不出現單點故障、無狀態等。依照 CAP 理論，分佈式系統只能在 CP 和 AP 之間做取捨。
2、Base 理論是在 CAP 理論上發展的，是 CAP 理論的實際應用，即在分區和副本存在的前提下，通過一定的系統設計方案，放棄強一致性，實現基本可用，比如 NoSQL 系統、微服務架構等。Base 理論主要包括三個部分，即基本可用（Basically Available）、軟狀態（Soft State）和最終一致性（Eventually Consistent）。最終一致性模型又包括因果一致性和會話一致性等。因果一致性 指的是要求有因果關係的操作順序得到保證，非因果關係的操作順序則無所謂；會話一致性 指的是將系統數據的訪問過程框定在一個會話之中，約定了系統能保證在同一個有效的會話中實現“讀己之所寫”的一致性。
3、系統在數據寫入成功之後，不承諾立即可以讀到最新寫入的值，也不會具體的承諾多久之後可以讀到，用戶讀到某一操作對系統數據的更新需要一段時間，我們稱這段時間爲“不一致性窗口”。
4、分佈式系統的三駕馬車分別是基於 RPC 的服務調用、基於 MQ 的事件驅動以及基於 Data Sync 的數據共享。
5、Zookeeper 是通過 Zab（Zookeeper Atomic Broadcast，Zookeeper 原子廣播協議）協議來保證分佈式事務的最終一致性。Zxid 是 Zab 協議的一個事務編號，Zxid 是一個 64 位的數字，低 32 位是一個簡單的單調遞增計數器，針對客戶端每一個事務請求，計數器 +1；高 32 位則代表 Leader 週期年代的編號。Zab 的具體流程可以拆分爲消息廣播、崩潰恢復和數據同步三個過程。
6、 pow（Proof of Work，工作量證明）被認爲是經過驗證最安全的拜占庭解決機制。
7、 異步化在分佈式系統設計中隨處可見，基於消息隊列的最終一致性就是一種異步事務機制，在具體實現上主要有本地消息表和第三方可靠消息隊列等。
8、 二階段提交協議
9、三階段提交協議
10、MySQL 的 XA 事務提交過程，以 redolog、binlog 日誌提交爲例，整體過程是先寫 redo log，再寫 binlog，並以 binlog 寫成功爲事務提交成功的標誌。
11、TCC 分佈式事務和 2PC/XA 兩階段提交的區別
- 2PC/XA 是數據庫或者存儲資源層面的事務，實現的是強一致性，在兩階段提交的整個過程中，一直會持有數據庫的鎖。
- TCC 關注業務層的正確提交和回滾，在 Try 階段不涉及加鎖，是業務層的分佈式事務，關注最終一致性，不會一直持有各個業務資源的鎖。
12、Redlock 算法是在單 Redis 節點基礎上引入的高可用模式，Redlock 基於 N 個完全獨立的 Redis 節點，一般是大於 3 的奇數個（通常情況下 N 可以設置爲 5），可以基本保證集羣內各個節點不會同時出現宕機。在 Redis 官方推薦的 Java 客戶端 Redisson 中，內置了對 RedLock 的實現。
13、分佈式系統怎麼保證消息隊列的時序性？先討論下爲什麼會產生時序性的問題，首先分佈式系統缺乏全局時鐘，不同的機器使用各自的本地時鐘，由於服務器存在時間偏斜等問題；其次，生產者集羣的發送時序無法保證，消息的分發過程也導致消費者集羣中不同消費實例的順序難以全局統一；最後，消息重傳也有可能導致順序發生不一致。
Kafka 保證消息在 Partition 內的順序，對於需要確保順序的消息，發送到同一個 Partition 中就可以。單分區的情況下可以天然滿足消息有序性，如果是多分區，則可以通過制定的分發策略，將同一類消息分發到同一個 Partition 中。
RocketMQ 對有序消息的保證和 Kafka 類似，RocketMQ 保證消息在同一個 Queue 中的順序性，也就是可以滿足隊列的先進先出原則。
除了消息隊列自身的順序消費機制，我們可以合理地對消息進行改造，從業務上實現有序的目的。比如：在每次寫入消息時，可以考慮添加一個單調遞增的序列 ID，在消費端進行消費時，緩存最大的序列 ID，只消費超過當前最大的序列 ID 的消息。這個方案和分佈式算法中的 Paxos 很像，雖然無法實現絕對的有序，但是可以保證每次只處理最新的數據，避免一些業務上的不一致問題。
14、分佈式系統怎麼保證消息隊列的冪等性？RPC 或者 MQ 的重試都有可能出現冪等性問題。解決方式上可以通過考慮 “中間件” + “業務”來處理。中間件比如設置 kafka 的語義：At most once、At least once、Exactly once ；業務上通過數據庫唯一索引、分佈式鎖等方式解決。
15、系統穩定性指標包括：服務器指標、系統運行指標、服務運用時指標、基礎組件指標。
16、常見的服務器監控指標：
17、常見的系統運行指標：
18、常見的基礎組件指標:
19、常見的監控組件：
- OpenFalcon：小米開源的一款企業級應用監控組件，是第一個國內開發的大型開源監控系統；
- Nagios：支持更豐富的監控設備，包括各類網絡設備和服務器；對不同的操作系統都可以進行良好的兼容；對各類交換機、路由器等都有很好的支持；
- Zabbix：基於 Server-Client 架構，可以實現各種網絡設備、服務器等狀態的監控；數據存儲可以根據業務情況，使用不同的實現，比如 MySQL、Oracle 等；Zabbix 的 Server 使用 C 語言實現，可視化界面基於 PHP 實現；
- CAT：Central Application Tracking 早期是大衆點評內部的監控組件，2014 年開源，基於 Java 開發；對各類分佈式服務中間件、數據庫代理層、緩存和消息隊列都有很好的支持；可以爲業務開發提供各個系統的性能指標、健康狀況，並且還可以進行實時報警；
20、監控處理制度：
21、引入 API 網關，可以高效的實現微服務集羣的輸出，節約後端服務開發成本，減少上線風險，併爲服務熔斷、灰度發佈、線上測試等提供方案；
22、API 網關在微服務架構中是用來整合各個不同模塊的微服務，統一協調業務；API 網關封裝了系統內部架構，爲每個客戶端提供了一個定製的 API；從面向對象設計的角度看，它與外觀模式（Facade Pattern）類似；
23、服務註冊與發現是保證當服務上下線發生變更時，服務消費者和服務提供者能夠保持正常通信；消費者不需要知道具體服務提供者的真實物理地址就可以進行調用，也不需知道具體有多少個服務者可用；服務提供者只需要註冊到註冊中心，就可以對外提供服務；
24、日誌的採集和存儲有很多開源的工具可以選擇，一般會使用 離線+實時 的方式去存儲日誌，主要是分佈式日誌採集的方式，典型的解決方案如 Flume 結合 Kafka 等 MQ，日誌存儲到 HBase 等存儲中；
25、在實際業務中，鏈路跟蹤系統會有一個採樣器配置，不會監控全部的鏈路。作爲非業務組件，應當儘可能少侵入或者無侵入其他業務系統並且儘量少的佔用系統資源；
26、Diamond：
27、Disconf：
28、NoSQL 數據庫可以從以下幾個角度進行分類：K-V 數據庫，比如 redis；文檔型數據庫，比如 mongoDB；列存儲數據庫，比如 Hbase；圖數據庫，比如 GraphDB、Neo；
29、分庫分表中間件實現：
- ShardingSphere：前身是噹噹開源的 Sharding-JDBC，已經加入 Apache 基金會，ShardingSphere 額外提供了 Sharding-Proxy，以及正在規劃中的 Sharding-Sidecar，其中 Sharding-JDBC 用來實現分庫分表，另外也添加了分佈式事務等的支持；
- TDDL：Taobao Distributed Data Layer，是淘寶團隊開發的數據庫中間件，用來解決分庫分表場景下的訪問路由。
30、RocketMQ 是阿里巴巴開源的一款消息中間件，使用 Java 語言開發；RocketMQ 在寫入磁盤時支持同步刷盤方式，即消息存儲磁盤成功，纔會返回消息發送成功的響應；RocketMQ 儘可能地保證了消息投遞中的順序一致性及可靠性，並且優化了響應時間；
31、Kafka 是 LinkedIn 開源的一個分佈式消息系統，主要使用 Scale 語言開發，已經加入 Apache 頂級項目；Kafka 可以非常方便地進行水平擴展，支持海量數據的傳輸；Kafka 的另外一個特點是高吞吐率，在消息持久化寫入磁盤的過程中使用了多種技術來實現讀寫的高性能，包括磁盤的順序讀寫、零拷貝技術等。
32、Kafka 的消費是基於 Topic 的，屬於發佈訂閱機制，它會持久化消息，消息消費完後不會立即刪除，會保留歷史消息，可以比較好的支持多消息者訂閱。
33、Kafka 爲了實現可擴展性，將一個 Topic 分散到多個 Partition 中；Partition 是一段連續的存儲，如果在同一個 Broker 上，不能掛載到多個磁盤；一個 Broker 可以對應多個 Topic，對應多個 Partition ；Partition 可以細分爲一個或多個的 Segment，每個 Segment 都對應一個 Index 索引文件，以及一個 log 數據文件；
34、爲了更好地做負載均衡，Kafka 會將所有的 Partition 均勻的分配到整個集羣上；爲了提高 Kafka 的系統容錯能力，一個 Partition 的副本，也要分配到不同的 Broker 上。
35、Kafka 的分區和副本分配遵循的原則：
- 一個 Topic 的 Partition 數量大於 Broker 的數量，使 Partition 儘量均勻分配到整個集羣上；
- 同一個分區，所有的副本要儘量均勻分配到集羣中的多臺 Broker 上；
- 儘可能保證同一個分區下的主從副本，分配到不同的 Broker 上；
36、引入副本機制之後，同一個 Partition 可能會有多個副本，如果 Leader 掛掉，需要從這些副本之間選出一個新的 Leader。Kafka 數據同步中有一個 ISR（In-Sync Replicas，副本同步隊列）的概念，隊列中的所有副本，都和 Leader 保持一致，Leader 節點在返回 ACK 響應時，會關注 ISR 中節點的同步狀態。
當所有的副本都掛了，Kafka 需要等待某個副本恢復服務：
- 等待 ISR 中的某個副本恢復正常，作爲新的 Leader（Kafka 的 ISR 依賴 ZK 進行管理）；
- ISR 列表是空，直接拋出 NoReplicationOnlineException 異常，保持一致性；
- ISR 列表是空，等待任一個副本恢復正常，作爲新的 Leader（可能會存在數據丟失，不能保證已經包含全部 Commit 的信息）；
37、Kafka 的零拷貝技術 —— MMAP 技術：Memory Mapped Files，直接對內存地址的操作。普通文件的 read 操作是把數據先讀取到內核空間中，然後再複製到用戶空間，而 MMAP 技術將文件直接映射到用戶態的內存空間，省去內核空間到用戶空間複製的開銷。
38、Kafka 的零拷貝技術 —— Sendfile：數據在內核緩衝區完成輸入和輸出，不需要拷貝到用戶空間處理。Kafka 把所有消息都存放在單獨的文件裏，在消息投遞時直接通過 Sendfile 方法發送文件；
39、Netty 關注的是網絡 IO 的傳輸；Kafka 等存儲關注的是文件 IO 的傳輸；