=======開篇吐槽：最近一段時間剛好碰上中秋國慶雙節，而且工作任務繁重，基本很難保證有時間來寫文章了=======

      《可伸縮服務架構 框架與中介軟體》與《分散式服務架構 原理、設計與實戰》是要配套捆綁著看，這營銷手段，服。

       這書主要介紹了在分散式系統中常規用到的一些框架元件，比如分散式ID、訊息佇列、快取、RPC框架、ES等。書中大部分內容的作用更多的是整體介紹、知識點擴充套件、初步入門，書中貼的原始碼其中很難讓人認真一行一行去閱讀學習。想要更深入的學習，需要在平時工作多積累豐富的專案經驗，或者多看看開源專案，從而去總結和提取。

       每一章介紹一個元件，摘抄一些自己覺得有用的內容，歸納整理，然後加以理解。（主要還是強迫自己形成總結成文的習慣，看的書很多，都總是很容易忘記，效果甚微

第1章 如何設計一款永不重複的高效能分散式發號器

1. 為什麼不直接採用UUID？

雖然UUID能夠保證唯一性，但無法滿足業務系統需要的很多其他特性，比如時間粗略有序性、可反解和可製造性（說人話，就是分散式ID需要體現根據時間遞增的特點，並且從ID串中能解析出一定的業務含義），同時UUID比較長，佔空間大，效能較差。

2. 那基於資料庫來實現呢？

即通過調整自增欄位或者資料庫sequence的步長來確保跨資料庫的ID的唯一性，但這種方案強依賴於資料庫。

3. 分散式ID的基本需求

（1）全域性唯一

分散式系統保證唯一的一個悲觀策略是使用鎖或者分散式鎖，但是這樣會大大降低效能。因此利用時間的有序性，並且在時間的某個單元下采用自增序列，來達到全域性唯一。

（2）粗略有序

UUID最大的問題是無序。

（3）可反解

即能從ID串能看出一定的業務含義，比如什麼時候產生的，跟哪些業務功能模組相關的。

（4）可製造

不依賴發號器（如果系統崩了），也能通過一定的規律來手工處理資料。

（5）高效能

產生一個新業務，就要生成一個新ID，所以對效能要求非常高。ID的生成取決於網路I/O和CPU的效能，網路I/O一般不是瓶頸。

（6）高可用

發號器應該是滿足HA的叢集，同時擁有重試機制。在極端情況下，還要有本地的容錯方案。

4. 如何保證效能需求？

在專案初期提出效能需求，在專案進行中做效能測試來驗證。

5. 獲取分散式ID的幾種方法

（1）REST方法

提供一個HTTP介面來獲取

（2）RPC服務化方法

服務化模式通過Dubbo匯出RPC服務

（3）嵌入方法

將發號器服務嵌入到業務專案中，並且提供JVM程序內的本地服務

第2章 可靈活擴充套件的訊息佇列框架的設計與實現

1. 背景介紹

訊息佇列多應用於非同步處理、模組之間的解耦和高併發系統的削峰等場景中。

2. 執行緒模型

（1）同步執行緒模型

客戶端為每個消費者流使用一個執行緒，每個執行緒負責從Kafka佇列裡消費訊息，並且在同一個執行緒裡處理業務。

（2）非同步執行緒模型

客戶端為每個消費者流使用一個執行緒，每個執行緒負責從Kafka佇列裡消費訊息，並且傳遞消費得到的訊息到後端的非同步執行緒池中，在非同步執行緒池中處理業務。

而後端的非同步業務執行緒池又可細分為：

1> 所有消費者流共享執行緒池

此種模式可以建立更少的執行緒池物件，節省些許記憶體

2> 每個流獨享執行緒池

使用不同的非同步業務執行緒池來處理不同的流裡面的訊息，互相隔離、互相獨立、不互相影響。比如，區分普通使用者的訊息，和VIP使用者的訊息，這樣可以在不同業務執行緒池中來處理。

3. 異常處理

對於在訊息處理過程中產生的業務異常，當前在業務處理的上層捕捉了Throwable，在專用的錯誤恢復日誌中記錄了出錯的資訊，後續可根據錯誤恢復日誌人工處理錯誤訊息，也可重做或者清洗資料。也可考慮採用Listener體系，對異常處理採用監聽者模式來實現異常處理器的可插拔等。

4. 優雅關機

通過註冊JVM退出鉤子進行優雅關機。

=========================繼續看下篇==========================