系統設計入門: Hashing
hashing基本功能為將不同格式的input轉換為固定長度的字串(或identifier)。
問題一：
當今天client 1先request Server A會留下cache紀錄，下一次再發相同的request就可以加速運作。但若依據round robin進行load balance，隔次實際上client 1被分配request到Server D。
例如透過編號，取mod(餘數)，再將特定client發送的request指向特定server。
note: 但這樣不就失去load balancer原本設定round robin的意義?
或者如果今天增加server E，透過重新編號，那又要重新分配，然後導致cache全部遺失，要重新累積。in-memory caching真是個災難!
或某個server壞掉後，又要如何重新進行分配?
Consistent Hashing
我們將hash funtion設計的更完整一點，以一個時鐘作為概念分割分配。
今天任意一個client進來透過hash function分配到固定位置上，而我們可以分配任意server到位置上，以順時針方式分配request。
例如
C2 分配給server C；
C3 分配給server B；
C1 原本分配給server A，但新增server E後，C1就分配給server E；
C4 分配給server A，但如果server A故障，則分配給server B。
目的在於
1. 維持系統可以持續運作(不受單一server crush影響)，並以
2.避免每次新增server都要重新分配(取mod的方式)。
實作consistent hashing方法(中文):
Consistent Hashing Algorithm: 應用情境、原理與實作範例
Rendezvous Hashing
或稱為 highest random weight hashing, HRW hashing
提出與其將特定request都一定要指派到一個server上，不如在一開始就建立server list順序，當今日有任一server故障時，就可以直接跳過，往下指派。
目的在於降低重新計算的loading，如下操作透過Rendezvous Hashing。
在右邊執行結果為採用一般方式，會全部重新分配，而Rendezvous Hashing只有原本server 5因為故障而重新分配了。
