海量數據處理

分庫分表的目的是爲了解決兩個問題：

第一，是數據量太大查詢慢的問題。這裏面咱們講的「查詢」其實主要是事務中的查詢和更新操做，由於只讀的查詢能夠經過緩存和主從分離來解決，這個咱們在以前的「MySQL 如何應對高併發」的兩節課中都講過。那咱們上節課也講到過，解決查詢慢，只要減小每次查詢的數據總量就能夠了，也就是說，分表就能夠解決問題。

第二，是爲了應對高併發的問題。應對高併發的思想咱們以前也說過，一個數據庫實例撐不住，就把併發請求分散到多個實例中去，因此，解決高併發的問題是須要分庫的。

簡單地說，數據量大，就分表；併發高，就分庫。

經常使用三種分片算法

• 範圍分片容易產生熱點問題，但對查詢更友好，適合適合併發量不大的場景；
• 哈希分片比較容易把數據和查詢均勻地分佈到全部分片中；
• 查表法更靈活，但性能稍差。

MySQL to Redis同步

• MQ消息同步
• 使用 Binlog 實時更新 Redis 緩存 （使用Canal）

如何實現不停機更換數據庫？

1. 上線同步程序，從舊庫中複製數據到新庫中，並實時保持同步；
2. 上線雙寫訂單服務，只讀寫舊庫；
3. 開啓雙寫，同時中止同步程序；
4. 開啓對比和補償程序，確保新舊數據庫數據徹底同樣；
5. 逐步切量讀請求到新庫上；
6. 下線對比補償程序，關閉雙寫，讀寫都切換到新庫上；
7. 下線舊庫和訂單服務的雙寫功能。

相似「點擊流」這樣的海量數據應該如何存儲？

對於海量原始數據的存儲系統，咱們要求的是超高的寫入和讀取性能，和近乎無限的容量，對於數據的查詢能力要求不高。生產上，能夠選擇 Kafka 或者是 HDFS，Kafka 的優勢是讀寫性能更好，單節點能支持更高的吞吐量。而 HDFS 則能提供真正無限的存儲容量，而且對查詢更友好。

目前已經有一些的開源項目

一類是分佈式流數據存儲，比較活躍的項目有Pravega和 Pulsar 的存儲引擎Apache BookKeeper。這些分佈式流數據存儲系統，走的是相似 Kafka 這種流存儲的路線，在高吞吐量的基礎上，提供真正無限的擴容能力，更好的查詢能力。

還有一類是時序數據庫（Time Series Databases），比較活躍的項目有InfluxDB和OpenTSDB等。這些時序數據庫，不只有很是好的讀寫性能，還提供很方便的查詢和聚合數據的能力。可是，它們不是什麼數據均可以存的，它們專一於相似監控數據這樣，有時間特徵而且數據內容都是數值的數據。若是你有存儲海量監控數據的需求，能夠關注一下這些項目。