A. java連接redis超時問題怎麼解決
應該是redis本身的服務有問題了
本文所針對的連接超時問題所涉及的相關元素如下:
Redis客戶端: Jedis (java)
Redis版本 :2.8.12
Redis部署操作系統類型:Linux
正文開始:
No 1.Redis執行大命令(時間復雜度為O(N)的命令)
問題剖析:
a.Redis伺服器端通過單線程處理命令,一旦有大命令被執行,Redis將無法及時響應來自客戶端的任何命令
關於Redis大命令的監控,可以查看slowlog來觀察
b.在使用jedis作為redis客戶端時,當redis連接池的配置參數testOnBorrow=true時,默認會在獲取redis連接
時,先執行redis的ping方法,而基於原因a,此時redis將無法及時響應,自然會報出time out異常
如何解決:
a.盡量避免使用時間復雜度為O(N)的命令
b.如果無法避免使用時間復雜度為O(N)的命令,則應降低其使用頻率,避免在業務高峰期時使用
No 2.Redis單次操作數據包過大
問題分析
a.單次操作數據包過大,且操作頻繁,極有可能會導致網路擁堵
b.在使用jedis作為redis客戶端時,當redis連接池的配置參數testOnBorrow=true時,默認會在獲取redis連接
時,先執行redis的ping方法,而基於原因a,此時redis將無法及時響應,自然會報出time out異常
如何解決:
a.排查代碼,確定是否存在大數據(數據條目過多/單條數據過大)操作,將其進行改造,改造方案有兩個:
a1.數據拆分,變更數據類型(常見的情況是將java中的collection類型序列化後存入redis的String數據
類型中),如將String數據類型調整為hash/list/set等,這常用於解決單條數據量過大的情況
a2.調整業務邏輯,減少單次數據查詢范圍(常見的情況如將redis中的整個hash數據取回,在應用程序內存中獲取需要的entry),如使用hget等單條查詢命令替換hgetall命令
B. scala怎樣創建redis集群連接池
此外，我還討論過較為常見的基於伺服器的數據存儲，比如MongoDB和CouchDB。每個數據存儲都有其優勢和劣勢，特別是當應用於特定領域時。本期的Java開發2.0關注的是Redis，一種輕量級鍵值對數據存儲。多數NoSQL實現本質上都是鍵值對，但是Redis支持非常豐富的值集，其中包括字元串、列表、集以及散列。因此，Redis通常被稱為數據結構伺服器。Redis也以異常快速而聞名，這使得它成為某一特定類型使用案例的最優選擇。當我們想要了解一種新事物時，將其同熟知的事物進行比較可能會有所幫助，因此，我們將通過對比其與memcached的相似性以開啟Redis探索之旅。接著我們將介紹Redis的主要功能，這些功能可以使其在某些應用場景可以勝過memcached。最後我將向您展示如何將Redis作為一個傳統數據存儲用於模型對象。Redis和memcachedMemcached是一個眾所周知的內存對象緩存系統，通過將目標鍵和值導入內存緩存運行。因此，Memcached能迴避讀取磁碟時發生的I/O成本問題。在Web應用程序和資料庫之間粘貼memcached時會產生更好的讀取性能。因此，對於那些需要快速數據查詢的應用程序，Memcached是一個不錯的選擇。其中的一個例子為股票查詢服務，需要另外訪問資料庫獲取相對靜態數據，如股票名稱或價格信息。MemcacheDB將Redis與memcached相比較並不公平，它與MemcacheDB相比要好的多，MemcacheDB是一個分布式鍵值對存儲系統，專為數據持久化而設計。MemcacheDB與Redis較為相似，其新增優勢可以使其輕松地與memcached實現的客戶端進行通信。但是memcached也有其局限性，其中一個事實就是它所有的值均是簡單的字元串。Redis作為memcached的替代者，支持更加豐富的功能集。一些基準(benchmarks)也表明Redis的速度要比memcached快很多。Redis提供的豐富數據類型使其可以在內存中存儲更為復雜的數據，這是使用memcached無法實現的。同memcached不一樣，Redis可以持久化其數據。Redis解決了一個重大的緩存問題，而其豐富的功能集又為其找到了其他用途。由於Redis能夠在磁碟上存儲數據以及跨節點復制數據，因而可以作為數據倉庫用於傳統數據模式（也就是說，您可以使用Redis，就像使用RDBMS一樣）。Redis還經常被用作隊列系統。在本用例中，Redis是備份和工作隊列持久化存儲（利用Redis的列表類型）的基礎。GitHub是以此種方法使用Redis的大規模基礎架構示例准備好Redis，立即開始!要開始使用Redis，您需要訪問它，可以通過本地安裝或者託管供應商來實現訪問。如果您使用的MAC，安裝過程可能就不那麼簡單。如果您使用的是Windows??，您需要先安裝Cygwin。如果您正在尋找一個託管供應商，Redis4You擁有一個免費計劃。不管您以何種方式訪問，您都能夠根據本文下列示例進行操作，但是我需要指出的是，使用一個託管供應商進行緩存可能並不是很好的緩存解決方案，因為網路延遲可能會抵消任何性能優勢。您需要通過命令與Redis進行交互，這就是說，這里沒有SQL類查詢語言。使用Redis工作非常類似於使用傳統map數據結構，即所有的一切都擁有一個鍵和一個值，每個值都有多種與之關聯的數據類型。每個數據類型都有其自己的命令集。例如，如果您計劃使用簡單數據類型，比如某種緩存模式，您可以使用命令set和get。您可以通過命令行shell與一個Reids實例進行交互。還有多個客戶端實現，可以以編程方式與Redis進行交互。清單1展示了一個使用基礎命令的簡單命令行shell交互：清單1.使用基礎的Redis命令redis127.0.0.1:6379>setpageregistrationOKredis127.0.0.1:6379>keys*1)"foo"2)"page"redis127.0.0.1:6379>getpage"registration"在這里，我通過set命令將鍵"page"與值"registration"相關聯。接著，我發出keys命令（後綴*表示我想看到所有可用的實例鍵。keys命令顯示有一個page值和一個foo，我可以通過get命令檢索到與一個鍵關聯的值。請記住，使用get檢索到的值只能是一個字元串。如果一個鍵的值是一個列表，那麼您必須使用一個特定列表的命令來檢索列表元素。（注意，有可以查詢值類型的命令）。Java與Jedis集成對於那些想要將Redis集成到Java應用程序的編程人員，Redis團隊建議使用一個名為Jedis的項目，Jedis是一個輕量級庫，可以將本地Redis命令映射到Java方法。例如Jedis可以獲取並設置簡單值，如清單2所示：清單2.Java代碼中的基礎Redis命令JedisPoolpool=newJedisPool(newJedisPoolConfig(),"localhost");Jedisjedis=pool.getResource();jedis.set("foo","bar");Stringfoobar=jedis.get("foo");assertfoobar.equals("bar");pool.returnResource(jedis);pool.destroy();在清單2中，我配置了一個連接池並捕獲連接，（與您在典型JDBC場景中的操作非常相似）然後我在清單的底部設置了返回操作。在連接池邏輯之間，我設置了值"bar"和鍵"foo"，這是我通過get命令檢索到的。與memcached類似，Redis允許您將過期（expiration）時間關聯到一個值。因此我設置了這樣一個值（比如，股票臨時交易價格），最終將從Redis緩存中清除掉。如果我想在Jedis中設置一個過期時間，需要在發出set調用之後將其和一個過期時間關聯。如清單3所示：清單3.Redis值可以設置為終止jedis.set("gone","daddy,gone");jedis.expire("gone",10);Stringthere=jedis.get("gone");assertthere.equals("daddy,gone");Thread.sleep(4500);StringnotThere=jedis.get("gone");assertnotThere==null;在清單3中，我使用了一個expire調用將"gone"的值設置為在10秒鍾內終止。調用Thread.sleep之後，"gone"的get調用會返回null。Redis中的數據類型使用Redis數據類型，比如列表和散列需要專用命令用法。例如，我可以通過為鍵附加值來創建列表。
C. 供應鏈金融風控系統流程是怎樣的
供應鏈金融風控系統流程是怎樣的呢？依據我們供應鏈金融風控系統的開發經驗，下面來為大家進行介紹。
前期准備
拿到足夠多的數據做支撐
做足夠靈活的分析平台去分析數據
產出風險事件進行阻攔風險
量化風險攔截的價值和不斷分析案例進行策略優化
風控技術評估研究
日誌選擇：以增量日誌方式記錄存儲，hadoop或spark做分析，集群同步到客戶端機器上，做同步策略，不同緯度的數據做統計加工計算。
實時監控：監控在每一個環節的交易量和高風險操作，做閥值報警，以默認的規則做處理。
dns防範：防止http對dns的攔截，手動紀錄中斷被攔截掉的交易流，轉向存儲中心系統做處理給予用戶提示。
報警提醒：在發生重大災難的同時需要有一套完善的體系提醒風控人員近入作戰，以簡訊或電話的形式發起通知給用戶。
數據災難：數據的歷史紀錄應該有完整的備庫紀錄，這種操作不是必須的但是必要的，防止管理員因為誤操作導致的數據災難不容小視，啟東應急方案進行恢復。
日誌選擇：需要在原有基礎上做集群數據分析後，統一有一個入口的分析平台做匯總，對不同維度的計算規則做排重，這里我們可以使用elk的方式把數據清洗完成後，做相關的分析調研，實時讀庫的方式不可取，增量資料庫只保留歷史的數據，可以對時間做相關的約定，查詢的平台統一做相關的調控。
方案的選擇和實施
針對現在的數據規則，需要對現有的各方數據做分析指標，做數據倉庫，從不同的數據中計算對應的需要風控形成各種渠道的報表數據。如何通過查詢海量的歷史數據來支撐規則的運算，從分析的角度來看，又是一個IO密集型的應用；利用OLTP（online transaction processing ）和OLAP（online analytical processing）做相關的維度計算，主要針對用戶、功能、數據片、存儲空間、DB設計來做維度計算和方案的優化調整。
大到用hadoop做數據集群演算法分析，也可以用spark、storm來做。
簡而言之就是分布式框架，那麼什麼是分布式框架？
分布式計算框架實現了什麼？簡而言之，基於分布式計算框架的應用，就是一個分布式的應用；那麼分布式的應用解決了什麼問題？簡而言之，就是將請求處理的業務邏輯和所需資源合理地分布到N台伺服器上，這里就不在過多介紹。
基於C/S模式的原理，從client到server端的應用，採集需要的數據。Server之間通訊是有開銷的，只不過這個開銷是MS級的。系統在定位也是基於百萬級的應用。
以分層的概念，針對每部的風控模塊，需要在特定的時間做調整。緩存的應用：如果是歷史級別的數據，可以採用redis、cache來做，防止減少對於I/O的讀寫操作，減少存儲壓力的開銷。基於款時間的維度對應的風控系統計算，需要我們在處理的同時考慮數據的節點，分批次處理。對於變化多端的數據，建議利用高可用性能存儲設計，基於DB設計即可，數據結構要基於範式(NF)設計，不可有冗餘免得頻繁返工。
數據分離的優先選擇
資料庫讀寫分離機制：在初期，風控系統一般都極為簡單，此時侯一般通過資料庫主從復制/讀寫分離/Sharding（或slave進行）等機制來保證交易系統的資料庫和風控系統數據的同步及讀寫分離。風控系統對所需要的客戶/賬戶數據、交易數據一般都只進行讀操作。
緩存/內存資料庫機制：不管是交易系統還是風控系統，高效的緩存系統是提升性能的大殺器，一般會把頻繁使用的數據存放到Redis等緩存系統中。例如對風控系統，包括諸如風控規則、風控案例庫、中間結果集、黑白名單、預處理結果等數據；對交易系統而言，包括諸如交易參數、計費模板、清結算規則、分潤規則、銀行路由策略等。對一些高頻交易中，基於性能考慮，會採用內存資料庫（一般會結合SSD硬碟）。
RPC/SOA架構：要降低交易系統和風控系統的耦合度，在初期系統服務較少的情況下，一般直接採用RabbitMQ/ActiveMQ之類的消息中間件或RPC方式來實現系統間服務的調用。如果系統服務較多，存在服務治理問題，會採用Dubbo之類的SOA中間件來實現系統服務調用，這個期間我們需要支持用非同步消息完成rabbitMQ的消息的push/pull處理機制來處理違規數據和異常數據提取。
D. h2資料庫和redis資料庫最大的區別
nosql 處理 雜亂非結構化數據設計 比 中國頁訪問信息 樓說 閹割sql acid 特性 快啊 比插入數據 相反些 交易數據 數據安全穩定 壓倒切候 rdbms 顯現威力 rdbms 面nosql 些挑戰 力優化 於些 非結構化數據支持 比json 數據 同rdbms 於 olap and oltp 支持 要比 nosql快點半點 總結 世界定東西 mongodb nosql 資料庫吧 要用做稍微復雜幾統計 家睡醒 再
E. Redis 秒殺系統的設計與實現
還記得剛工作那會，每每聽到大牛們聊技術，各種專業術語，巴拉巴拉的，簡直像是在聽天書，比如什麼中間件、分布式、SOA、無狀態、熱更新、懶載入、ACID、LVS、LDAP、VIP、CDN、負載均衡、魯棒性、POJO、DSL、DI、IOC，太多太多了。一轉眼快 10 年過去了，當很多新人再問到我這些名詞的時候，我就在想，能不能用通俗易懂的大白話，就能聊明白這些專業的技術知識呢？
最近，給幾個公司做技術咨詢，經常會聊到秒殺系統。所以，借這次機會，嘗試用大白話和大家聊聊 Redis 秒殺系統的設計與實現，。
說起 「秒殺」，我相信大家肯定都耳熟能詳了，雙十一零點搶購、手機整點搶購、搶火車票、1 元秒殺、搶紅包等等，都可以說是秒殺的各種應用場景了。
秒殺系統的設計 ，難就難在，在極短的時間內，應對瞬時湧入平時成百上千倍的巨大流量，還包括各種攻擊刷量作弊等未知流量，最終我們要保證在用戶體驗順暢良好的情況下，不能多賣或者少賣。
而當我們公司決定要做秒殺系統的時候，我就去找業務，到時大概會有多少 UV，不知道 10 倍或者 100 倍？然後去找老闆，給技術多少預算，最多平時的 10 倍不能再多了，當然越少越好，呵呵，也就是說讓我們用平時最多 10 倍的預算去解決不可預估的用戶流量，怎麼做？要是有錢直接扔 1 萬台伺服器跑去吧，錢能解決的事就不是事，但問題是現在還沒那麼多錢，還要把事情搞定。
在聊秒殺系統設計之前，讓我們先回到現實生活中，聊聊常見的「秒殺」場景和秒殺場景的獨有特點，以及它們都是怎麼應對的，在應對過程中都需要注意什麼。
日常生活中，其實也有很多秒殺場景，比如，早上 9 點超市開門，老大爺老大媽搶購蔬菜水果，是不是？ 還有，新樓盤開盤搶購，是不是？ 股市開盤、交易所現場，是不是？
對的，生活中其實有太多類似場景了， 你有沒有發現「秒殺」的獨有特點呢？
記住了上面三個特點，我們就可以區分和確定秒殺的業務場景了。 這里我舉一個特別的例子， 你說擠公交車，算不算秒殺場景呢？
下面，我再和大家聊一個關於搶豬肉的故事。
在保安部門充分討論之後，保安大隊長決定通過以下安排，在保證人員安全的前提下，還要做到相對公平。
後來，活動井然有序的開始了，但是由於豬肉銷售場地太遠，銷售窗口又少，老大爺和老大媽們買肉又精挑細選，導致整個過程很漫長，而且外面等候的人們都開始騷動起來，這個時候保安大隊長趕緊找到經理：
故事講完了，如果我們把上面的故事，理解為秒殺業務場景，我們就可以總結出一個 秒殺系統的設計原則 了：
F. 風控系統實踐之感: drools 和 redis
需求:
開發一個風控系統，系統包括, 規則引擎和計算引擎, 主要的內容如下:
1. 規則的增刪改和實時生效, 規則的分類執行
2. 按照一定的緯度計算累計值，比如按照 IP, 用戶 id, 賬戶 等緯度。
3. 需要支持滑動窗口，滾動窗口，長度窗口等
遇到的問題主要有以下幾點:
1. redis 做流計算太過勉強，一是根據業務上的需求，需要統計的key 至少有幾億個，最多也有幾十億個，另外redis 中需要存儲少量的交易的信息。估算下來量也是非常可觀
2. redis 中 hot key 特別明顯，比如按照商戶的緯度去統計，如果不對商戶的key 進行拆封，像盒馬那種流量的商戶，對redis 的壓力是非常大的。
我們採用的是redis 的cluster 模式，這樣的話redis hot key 對redis 影響會更大。對其進行拆分是非常必要的，比如 按照小時拆分。
3. 流式計算中，一個是亂序導致累加的計算不準確(有負值)，另外一個是消息延遲. 當時我們嘗試使用flink 中的水印的概念去解決問題，發現並不適合。這個坑也是我們實踐過後才發現的。
最痛苦的經歷是亂序和延遲消息的解決，現在是採取糾正的方式解決。
規則引擎
規則引擎我們選用了drools，簡單的探索了drools core, drools DRL, drools CEP 等，但是回頭看看，針對drools的使用缺點還是很多, 而且很明顯，暫時還沒有替換的打算.
1. 使用 drools CEP 如何做分布式? 我們發現drools CEP中的幾種窗口都是內存計算的，應用到分布式中就沒有很好的辦法，幾乎做不到，除非drools 也去集成redis等這種分布式緩存。
2. 使用drools 覺得很笨重，因為依賴比較多，二是我們只用到了 drools 中的 if else 等判斷，許多其它的功能基本就用不到，因為 1 中解決不了分布式的問題。所以從這點來說drools 已經廢了，根本不用在創建kiesession 這種 重量級的東西。
3. drools中支持的運算符不是特別充分，比如像 log 運算，sum, max, avg 這種的運算等都是不支持的. DRL 語言對業務人員來說不是非常的友好。
4. 另外drools 中的 連續，非連續的規則，沒有看出來如何配置，至少flink cep 是有這樣API的。
綜上所描述，不得不吐槽下 drools真是無語，也許了解的很簡單，還有別的方式，另外drools workbench 也是很無語，很復雜，估計drools 廠商想通過這種方式掙錢。
總體感覺，如果有別的選擇，最好不要選用drools，分布式的問題沒有解決，就等於廢了，因為各種分布式窗口都需要我們自己去實現。怎麼辦呢?
規則引擎最後還是採用了drools，根據具體的業務含義創建不同的kiesession, drools 起到了if else 判斷的作用，至於滾動窗口，長度窗口和滑動窗口都通過redis來做計算。遇到頭疼的問題，是
1. 根據不同的統計緯度，大概計算了下，需要幾十億個key，在redis 中做計算
2. 滑動窗口暫時靠 redis的zsort 的數據結構，性能不是非常好
3. 熱點key 的問題，特別對於大商戶的熱點key 的問題，需要做拆分，拆分起來是比較復雜的
4. 消息延遲和消息亂序問題。
所以計算引擎的需求一般是
1. 計算很快，大幾百個規則，能夠很快的計算出准確的結果來
2. 計算準確率，當面對亂序和延遲消息的時候，如何計算的更加准確
3. 計算的量的問題，正如前面提到的，幾十億個key，另外還需要存儲一些信息，計算的中間狀態等，如何在redis 中丟失，就會造成計算不準確。
基於以上的問題，關鍵是如何做的更好，優化的更好，說實話，我沒有找到答案，可以做的就是不斷的優化redis 計算(暫時不能上大數據，比如flink， spark 等)，減少redis 的操作帶來的網路開銷。
其實最後還要提一下，如果能採用內存計算，不用分布式計算，會不會速度更快點，比如根據業務來做分片，這樣在各個實例統計的中間值就不用匯總，那麼每個實例只需要內存計算就好，不需要訪問redis而帶來的網路開銷。但是這樣做也會帶來架構層面的調整，比如 如何做 fault tolerance， 如何做 狀態持久化, 等一系列的問題。
從使用redis結果來看，效果也不是那麼差，不考慮非常熱點key 的情況下，最高tps 也達到6000多(2 台機器，16core，32G 內存), 一般公司的業務其實是可以滿足的，對於非常熱點的key，後續的優化是繼續拆分.
一個好的風控系統是非常難的，做以筆記，以希望不斷成長
G. loadrunner 怎麼通過redis中間件發交易
1、接到項目時，首先了解系統架構，是B/S，還是C/S，使用什麼應用伺服器（即中間件），什麼資料庫？ 2、熟悉系統的功能、業務流程，明確項目的性能需求是什麼？有哪些性能指標？ 3、編寫性能測試計劃。（有些公司不要求寫）
H. java中如何構造ADT 數字貨幣
無論是股票交易系統，還是數字貨幣交易系統，都離不開撮合交易引擎，這是交易平台的心臟。同時，一個優秀的架構設計也會讓交易平台的運維和持續開發更加容易。本文基於對開源項目的深入研究，總結了數字貨幣交易系統的架構設計。
關於撮合交易系統
撮合技術主要是從資料庫撮合技術向內存撮合技術發展，這是因為資料庫撮合技術越來越無法滿足金融交易對於高可靠性、高性能、強安全性、可擴展性以及易維護性的需求。金融（幣幣）交易撮合系統中包括以下幾個核心模塊:
用戶：終端用戶委託報價與數量,生成訂單發送至交易平台。
網關：負責收集用戶訂單,並將其派發給撮合引擎。
撮合引擎：交易系統中的核心部分,用於接收訂單並根據業務邏輯實現訂單 撮合同時生成交易記錄,隨後給予用戶交易結果反饋。
資料庫：用來存放交易過程中的訂單和交易記錄,實現數據持久化。
消息隊列：一般用於訂單消息的傳輸
關於技術選型
一個交易所平台的技術架構主要考慮安全性、分布式、易擴展、容錯性、低延時、高並發等特性，以及熔斷機制、服務注冊和發現、消息服務、服務網關、安全認證、內存資料庫、關系型資料庫等各種選項，最終形成了如下技術選型：
分布式基礎進行架構SpringCloud與Dubbo之間二選一，由於SpringCloud更加知名，SpringCloud的程序員更好招聘，有利於系統的長期運維升級，而且SpringCloud是基於SpringBoot開發，比較有親切感，所以選擇了SpringCloud, 其實由於阿里系的強大影響，國內Dubbo使用更加廣泛，不同的團隊可以根據自己的情況選擇。
引入Hystrix斷路器作為容錯保護模塊，防止單個服務的故障，耗盡整個撮合系統容器的線程資源，避免分布式環境里大量級聯失敗。對通過第三方客戶端訪問依賴服務出現失敗、拒絕、超時或短路時執行回退邏輯。
採用Eureka作為服務注冊與發現中心，實現中間層服務，以達到負載均衡和中間層服務故障轉移的目的。
服務網關Spring Cloud Gateway 與 Zuul 的選型，選擇了Zuul，因為名字短一些。
引入SpringCloud Security安全認證模塊用於構建安全的應用程序和服務，SpringCloud Security在Spring Boot和Spring Security OAuth2的基礎上，可以快速創建和實現常見的安全認證方式，如單點登錄，令牌中繼和令牌交換等。
引入Redis作為內存資料庫，兼做系統數據緩存和內存計算。
使用MySQL作為關系資料庫，性能測試非常過關，而且對熟悉MYSQL的程序員非常友好。
消息隊列中間件MQ採用了Kafka, 具有超高性能體現。
I. redis最大多少個節點問題
轉自 https://blog.csdn.net/chenxuegui1234/article/details/100171599
現在redis集群架構，redis cluster用的會比較多。
如下圖所示
對於客戶端請求的key，根據公式HASH_SLOT=CRC16(key) mod 16384，計算出映射到哪個分片上，然後Redis會去相應的節點進行操作！
那大家思考過，為什麼有16384個槽么?
ps:CRC16演算法產生的hash值有16bit，該演算法可以產生2^16-=65536個值。換句話說，值是分布在0~65535之間。那作者在做mod運算的時候，為什麼不mod65536，而選擇mod16384？
其實我當初第一次思考這個問題的時候，我心裡是這么想的，作者應該是覺得16384就夠了，然後我就開始查這方面資料。
很幸運的是，這個問題，作者是給出了回答的！
地址如下: https://github.com/antirez/redis/issues/2576
作者原版回答如下:
The reason is:
So 16k was in the right range to ensure enough slots per master with a max of 1000 maters, but a small enough number to propagate the slot configuration as a raw bitmap easily. Note that in small clusters the bitmap would be hard to compress because when N is small the bitmap would have slots/N bits set that is a large percentage of bits set.
因此，能看懂上面那段話的讀者。這篇文章不用看了，因為作者講的很清楚了。本文只是對上面那段話做一些解釋而已。
我們回憶一下Redis Cluster的工作原理！
這里要先將節點握手講清楚。我們讓兩個redis節點之間進行通信的時候，需要在客戶端執行下面一個命令
<pre style="box-sizing: border-box; outline: 0px; margin: 0px 0px 24px; padding: 8px; font-weight: 400; position: relative; white-space: pre-wrap; overflow-wrap: break-word; overflow-x: auto; font-family: Consolas, Inconsolata, Courier, monospace; font-size: 14px; line-height: 22px; color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-style: initial; text-decoration-color: initial;">127.0.0.1:7000>cluster meet 127.0.0.1:7001
</pre>
如下圖所示
意思很簡單，讓7000節點和7001節點知道彼此存在！
在握手成功後，兩個節點之間會 定期 發送ping/pong消息，交換 數據信息 ，如下圖所示。
在這里，我們需要關注三個重點。
到底在交換什麼數據信息？
交換的數據信息，由消息體和消息頭組成。
消息體無外乎是一些節點標識啊，IP啊，埠號啊，發送時間啊。這與本文關系不是太大，我不細說。
我們來看消息頭，結構如下
注意看紅框的內容，type表示消息類型。
另外，消息頭裡面有個myslots的char數組，長度為16383/8，這其實是一個bitmap,每一個位代表一個槽，如果該位為1，表示這個槽是屬於這個節點的。
到底數據信息究竟多大？
在消息頭中，最占空間的是myslots[CLUSTER_SLOTS/8]。這塊的大小是:
16384÷8÷1024=2kb
那在消息體中，會攜帶一定數量的其他節點信息用於交換。
那這個其他節點的信息，到底是幾個節點的信息呢？
約為集群總節點數量的1/10，至少攜帶3個節點的信息。
這里的重點是: 節點數量越多，消息體內容越大。
消息體大小是10個節點的狀態信息約1kb。
那定期的頻率是什麼樣的？
redis集群內節點，每秒都在發ping消息。規律如下
因此，每秒單節點發出ping消息數量為
1+10*num（node.pong_received>cluster_node_timeout/2）
那大致帶寬損耗如下所示，圖片來自《Redis開發與運維》
講完基礎知識以後，我們可以來看作者的回答了。
(1)如果槽位為65536，發送心跳信息的消息頭達8k，發送的心跳包過於龐大。
如上所述，在消息頭中，最占空間的是myslots[CLUSTER_SLOTS/8]。
當槽位為65536時，這塊的大小是:
65536÷8÷1024=8kb
因為每秒鍾，redis節點需要發送一定數量的ping消息作為心跳包，如果槽位為65536，這個ping消息的消息頭太大了，浪費帶寬。
(2)redis的集群主節點數量基本不可能超過1000個。
如上所述，集群節點越多，心跳包的消息體內攜帶的數據越多。如果節點過1000個，也會導致網路擁堵。因此redis作者，不建議redis cluster節點數量超過1000個。
那麼，對於節點數在1000以內的redis cluster集群，16384個槽位夠用了。沒有必要拓展到65536個。
(3)槽位越小，節點少的情況下，壓縮率高
Redis主節點的配置信息中，它所負責的哈希槽是通過一張bitmap的形式來保存的，在傳輸過程中，會對bitmap進行壓縮，但是如果bitmap的填充率slots / N很高的話(N表示節點數)，bitmap的壓縮率就很低。
如果節點數很少，而哈希槽數量很多的話，bitmap的壓縮率就很低。
ps：文件壓縮率指的是，文件壓縮前後的大小比。
綜上所述，作者決定取16384個槽，不多不少，剛剛好！