海量数据处理

分库分表的目的是为了解决两个问题：

第一，是数据量太大查询慢的问题。这里面咱们讲的“查询”其实主要是事务中的查询和更新操做，由于只读的查询能够经过缓存和主从分离来解决，这个咱们在以前的“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等。这些时序数据库，不只有很是好的读写性能，还提供很方便的查询和聚合数据的能力。可是，它们不是什么数据均可以存的，它们专一于相似监控数据这样，有时间特征而且数据内容都是数值的数据。若是你有存储海量监控数据的需求，能够关注一下这些项目。