评价互联网产品,通常会有一项重要指标,那就是用户量,随着物联网的发展,越来越多的信息被记录到网络中。
这对数据库的性能就有了更高的要求,不论哪种数据库,都不可能无限量的存储数据,对于 MySQL 来说,一张表的数据量最好控制在 3000 万以下。如果数据量达到了亿级,增删改查都会变得很慢。如果说 3000 万到 5000 万时,性能是缓慢降低,那么 5000 万上升到 8000 万时,性能就会接近垂直的下降。
MySQL 架构的要素
在选择 MySQL 架构时,通常要考虑以下三个问题:
一致性
主从库之间的数据同步问题,容易造成数据丢失。
高并发
集群中的负载均衡问题。
高可用
当出现灾难时,恢复正常运行的延迟问题。
实际上,没有能同时解决这三个问题的架构,我们只能根据业务需求来选择。
MySQL 架构对比
主从 | MHA | PXC | keepalived + LVS | |
---|---|---|---|---|
适用业务 | 高并发、读写分离 | 高并发、读写分离、自动故障转移 | 高并发、读写分离、自动添加节点、自动故障转移、强一致性要求 | 高并发、读写分离、自动故障转移 |
部署方式 | MySQL 原生高可用方式 | 不影响线上业务 | 重新安装 | 不影响线上业务 |
多点写入 | 不支持 | 不支持 | 支持 | 不支持 |
一致性 | 可能丢数据 | 可能丢数据 | 强一致性、不丢失数据 | 可能丢数据 |
切换时间 | 手动 | 0~30 秒 | 0 秒 | 1~5 秒 |
维护难度 | 繁琐 | 自动 | 自动 | 自动 |
增减节点 | 手动 | 手动 | 自动 | 手动 |
性能影响 | 无 | 无 | 不适合大事务 | 无 |
缺点 | 需要人工维护 | 存在误判的可能 | 大事务支持差 | 可能出现脑裂 |