從hashMap/mysql/redis/到分佈式
1 HashMap
問題：從一個大數組(10000)中，找到特定的X。
通常的解答：都是循環遍歷一遍，查找X，需要全量IO。
優化
把大數據量，分爲小數據量(4個數字)的組合。組成了2500個4個小數組。
分而治之，依賴索引 / 路由 / hash 。
X 計算hash值。hashcode % 2500
HashMap 或者 HashTable 的原理。
優化後的查找過程：計算X的hash值，查找索引（左側），定位X的大致位置，根據索引查找小數組。一定比全量IO快。
問題：可能數據大部分都落在一個hash值內，效率會降低。
總結：
只做分治，不一定能夠提速。
大數據查詢，要使用分治。
2 mysql
爲什麼存數據，要出來這麼多的技術？
答：因爲要快。
爲什麼快？
誰快？
誰慢？
總結：
同樣的數據，存在文件中，速度慢。
但是，存在數據庫中，會快很多，爲什麼？
答：
下圖解決。
數據庫高併發場景，都命中索引，慢？
因爲什麼：
吞吐量限制。
IO 一秒返回64M，但是總共數據要返回 512M 。
數據庫有 TPS 、PVS 的閾值限制，超過之後就會很慢。
—》分庫、分表解決等。
數據庫的硬傷：
磁盤IO。
答：datapage 4KB. 做分治。4K對齊。
HDFS block 大小。應該設置符合機器性能，不應該設置太大。
二級索引的作用：避免全量IO（全量遍歷索引）的過程。
問題：
如果要查找的內容，沒有做過索引？
——也就是索引沒有命中。
那麼就會走全量IO.
怎麼解決數據庫的問題？
答：數據有特徵，不是每個數據每天都要查詢，熱數據的概念。只要保證熱數據訪問夠快，用戶感官上整理快。—》引出：redis、memcache（緩存）。
3 redis
問題1：redis爲什麼不支持sql。
答：因爲redis存儲的是部分數據，所以通過sql查詢，結果不完整。
問題2：redis 爲什麼快？
答：以下三點：
worker 單線程模型，所以快。
問題：
單線程爲什麼就快？
使用內存。
6.x IO 使用多線程。
redis value有類型，每種類型有本地方法。
秒殺場景，一定要用redis。語境：高併發。
四層LVS 或者 7層Ngnix反向代理
串行化：每個server請求加鎖。
HBase
區別於redis，能存全量數據。
以上內容整理自：馬士兵教育，周志壘老師公開課。
本文分享自微信公衆號 - 哥妞（gh_d18ec82f19ea）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。