MySQL（架构）[先导篇]

评价互联网产品，通常会有一项重要指标，那就是用户量，随着物联网的发展，越来越多的信息被记录到网络中。
这对数据库的性能就有了更高的要求，不论哪种数据库，都不可能无限量的存储数据，对于 MySQL 来说，一张表的数据量最好控制在 3000 万以下。如果数据量达到了亿级，增删改查都会变得很慢。如果说 3000 万到 5000 万时，性能是缓慢降低，那么 5000 万上升到 8000 万时，性能就会接近垂直的下降。

MySQL 架构的要素

在选择 MySQL 架构时，通常要考虑以下三个问题：

一致性

主从库之间的数据同步问题，容易造成数据丢失。

高并发

集群中的负载均衡问题。

高可用

当出现灾难时，恢复正常运行的延迟问题。

实际上，没有能同时解决这三个问题的架构，我们只能根据业务需求来选择。

MySQL 架构对比

	主从	MHA	PXC	keepalived + LVS
适用业务	高并发、读写分离	高并发、读写分离、自动故障转移	高并发、读写分离、自动添加节点、自动故障转移、强一致性要求	高并发、读写分离、自动故障转移
部署方式	MySQL 原生高可用方式	不影响线上业务	重新安装	不影响线上业务
多点写入	不支持	不支持	支持	不支持
一致性	可能丢数据	可能丢数据	强一致性、不丢失数据	可能丢数据
切换时间	手动	0~30 秒	0 秒	1~5 秒
维护难度	繁琐	自动	自动	自动
增减节点	手动	手动	自动	手动
性能影响	无	无	不适合大事务	无
缺点	需要人工维护	存在误判的可能	大事务支持差	可能出现脑裂