《架構師之路》（58沈劍） 讀書筆記

原由是前兩天在掘金刷到這個

後端架構師技術圖譜

一個很是詳細的java後端技術集合，裏面就提到了這本書，這本書暫時還沒出版好像？

在ws3cshcool能夠讀到www.w3cschool.cn/architectro…
初看就感受出來是本對後端架構技術概況的很好的書。做者文筆清晰，技術精湛。我就邊讀邊作筆記了。

互聯網架構設計如何進行容量評估：

【步驟一：評估總訪問量】

->詢問業務、產品、運營

【步驟二：評估平均訪問量QPS】

->除以時間，一天算4w秒

【步驟三：評估高峯QPS】

->根據業務曲線圖來

【步驟四：評估系統、單機極限QPS】

->壓測很重要

【步驟五：根據線上冗餘度回答兩個問題】

-> 估計冗餘度與線上冗餘度差值

N核服務器，經過執行業務的單線程分析出本地計算時間爲x，等待時間爲y，則工做線程數（線程池線程數）設置爲 N*(x+y)/x，能讓CPU的利用率最大化。

文章寫了很長，最後作一個簡單總結，面對100億數據量，1萬列屬性，10萬吞吐量的業務需求，58同城的經驗，是採用了元數據服務、屬性服務、搜索服務來解決的。

tcp-server 不是很懂

如何保證高可用？

客戶配置多個tcp-server的域名。

如何防止DNS劫持，以及加速？

IP直通車，客戶端配置多個tcp-server的IP。

如何保證擴展性？

服務端提供get-tcp-ip接口，向client屏屏蔽負載均衡策略，並實施便捷擴容。

對比「全局配置」與「配置中心」的架構圖，會發現配置由靜態的文件 升級爲 動態的服務：
1）整個配置中心子系統由zk、conf-center服務，DB配置存儲與，conf-web配置後臺組成

2.4如何提升數據庫的擴展性？原來用hash的方式路由，分爲2個庫，數據量仍是太大，要分爲3個庫，勢必須要進行數據遷移，58同城有一個很帥氣的「數據庫秒級擴容」方案。擴容步驟：第一步，將一個主庫提高

第二步，修改配置，2庫變4庫（原來MOD2，如今配置修改後MOD4）擴容完成

爲了解決主從數據庫讀取舊數據的問題，經常使用的方案有四種：（1）半同步複製（2）強制讀主（3）數據庫中間件（4）緩存記錄寫key

3若是有了數據庫中間件，全部的數據庫請求都走中間件。既然數據庫中間件的成本比較高，有沒有更低成本的方案來記錄某一個庫的某一個key上發生了寫請求呢？4很容易想到使用緩存，當寫請求發生的時候：

從mysql並行複製縮短主從同步時延的思想能夠看到，架構的思路是相同的：

（1）多線程是一種常見的縮短執行時間的方法

（2）多線程併發分派任務時必須保證冪等性：mysql的演進思路，提供了「按照庫冪等」，「按照commit_id冪等」兩種方式，思路大夥能夠借鑑

另，mysql在並行複製上的逐步優化演進：

mysql5.5 -> 不支持並行複製，對大夥的啓示：升級mysql吧

mysql5.6 -> 按照庫並行複製，對大夥的啓示：使用「多庫」架構吧

mysql5.7 -> 按照GTID並行複製

今天介紹瞭解決「跨N庫分頁」這一難題的四種方法(https://www.w3cschool.cn/architectroad/architectroad-cross-database-paging.html)：

方法一：全局視野法

（1）將order by time offset X limit Y，改寫成order by time offset 0 limit X+Y

（2）服務層對獲得的N*(X+Y)條數據進行內存排序，內存排序後再取偏移量X後的Y條記錄

這種方法隨着翻頁的進行，性能愈來愈低。

方法二：業務折衷法-禁止跳頁查詢

（1）用正常的方法取得第一頁數據，並獲得第一頁記錄的time_max

（2）每次翻頁，將order by time offset X limit Y，改寫成order by time where time>$time_max limit Y

以保證每次只返回一頁數據，性能爲常量。

方法三：業務折衷法-容許模糊數據

（1）將order by time offset X limit Y，改寫成order by time offset X/N limit Y/N

方法四：二次查詢法

（1）將order by time offset X limit Y，改寫成order by time offset X/N limit Y

（2）找到最小值time_min

（3）between二次查詢，order by time between $time_min and $time_i_max

（4）設置虛擬time_min，找到time_min在各個分庫的offset，從而獲得time_min在全局的offset

（5）獲得了time_min在全局的offset，天然獲得了全局的offset X limit Y

所謂序列化（Serialization），就是將「對象」形態的數據轉化爲「連續空間二進制字節流」形態數據的過程，以方便存儲與傳輸。這個過程的逆過程叫作反序列化。

無論使用成熟協議xml/json，仍是自定義二進制協議來序列化對象，序列化協議設計時要考慮哪些因素呢？

（1）解析效率：這個應該是序列化協議應該首要考慮的因素，像xml/json解析起來比較耗時，須要解析doom樹，二進制自定義協議解析起來效率就很高

（2）壓縮率，傳輸有效性：一樣一個對象，xml/json傳輸起來有大量的xml標籤，信息有效性低，二進制自定義協議佔用的空間相對來講就小多了

（3）擴展性與兼容性：是否可以方便的增長字段，增長字段後舊版客戶端是否須要強制升級，都是須要考慮的問題，xml/json和上面的二進制協議都可以方便的擴展

（4）可讀性與可調試性：這個很好理解，xml/json的可讀性就比二進制協議好不少

（5）跨語言：上面的兩個協議都是跨語言的，有些序列化協議是與開發語言緊密相關的，例如dubbo的序列化協議就只能支持Java的RPC調用

（6）通用性：xml/json很是通用，都有很好的第三方解析庫，各個語言解析起來都十分方便，上面自定義的二進制協議雖然可以跨語言，但每一個語言都要寫一個簡易的協議客戶端

（7）歡迎你們補充…

升級RPC-client內部的鏈接池，在service鏈接選取上作微小改動，就可以實現「id串行化」，實現不一樣類型的業務gid/uid等的串行化、序列號需求（這下查找日誌就方便了，一個羣gid/用戶uid的日誌只需去一臺機器grep啦）。