变更项目的整体架构是性能收益最大的方式。主要涉及两方面,一方面是从整个项目角度,引入一些中间件优化整体性能,另一方面是调整MySQL的部署架构,确保能承载更大的流量访问,提高数据层的整体吞吐。
1. 引入缓存中间件解决读压力
正常的项目业务中,读请求的数量远超写请求,所有的读请求都落入数据库处理,对MySQL会造成巨大的访问压力,甚至会由于流量过大,直接将数据库打到宕机,通常都会在应用程序和数据库之间架设一个缓存来解决这个问题,例如最常用的Redis。
在缓存Key设计合理的情况下,至少能够为MySQL分担70%以上的读压力,查询MySQL之前先查询一次Redis,Redis中有缓存数据则直接返回,没有数据时再将请求交给MySQL处理,从MySQL查询到数据后,再次将数据写入Redis,后续有相同请求再来读取数据时,直接从Redis返回数据即可。
2. 引入消息中间件解决写压力
项目中存在写操作比较频繁的时候,通过引入MQ消息中间件做削峰填谷。项目中核心的业务直接到MySQL执行落库操作,一些不重要的操作先发往MQ,MQ写入成功后直接将结果返回,后续在由消费线程去执行。
3. MySQL主从读写分离
当经过Redis、MQ后,必须要走MySQL执行的请求还是超出单机MySQL的承载范围,并且MySQL就是以单机的形式在线上运行,会出现频繁宕机的情况。
有三种MySQL架构的优化方案:主从架构,双主架构、分库分表架构。
主从复制,大多数中间件都会存在的一种高可用机制,MySQL中也存在这种架构,使用两台服务器来部署两个MySQL节点,一台为主机,另一台为从机,从节点会一直不断的从主节点上同步增量数据,当主节点发生故障时,从节点可以替换原本的主节点,以此来为客户端提供正常服务,
从节点仅作为一个备胎,难免有些浪费资源,可以在主从架构的模式下,略微做些调整,即实现读写分离,由于读操作并不会变更数据,对于读请求可以分发到从节点上处理,会引发数据变更的写请求,则分发到主节点处理,这样从而能够进一步提升MySQL的整体性能。
主节点的数据变更后,从节点也会基于bin-log日志去同步数据,但这种模式下会存在些许的数据不一致性,同步是需要时间的,向主节点修改一条数据后,立马去从节点中查询,这时不一定能够看到最新的数据,因为这时数据也许还未被同步过来。并没有太好的办法解决,项目对数据的实时性特别高就不要考虑主从架构。
4. MySQL双主双写热备
读写分离更适用于读大于写的业务。写大于读的业务从机分担的仅是系统的10~20%流量,所以双主双写(双柱热备)是最佳的选择。
两个MySQL节点都是主,同时都为从,两者之间相互同步数据,同时具备处理读/写请求的能力,出现读/写操作时,可由任意一个节点处理。
对于每张表的主键要处理好,如果表的主键是int自增类型的,要手动设置一下自增步长和起始值,比如这里有两个MySQL节点,将步长设置为2,起始值分别为1、2,能够确保主键的唯一性,设置后两个节点自增ID的序列如下:
-
- 节点1:[1、3、5、7、9、11、13、15、17、19.....]
- 节点2:[2、4、6、8、10、12、14、16、18、20.....]
当插入数据的SQL语句发往节点1时,会按照奇数序列自增ID,发往节点2时会以偶数序列自增ID,双方相互同步数据,最终两个MySQL节点都会具备完整的数据,因此后续的读请求,无论发往哪个节点都可以读到数据。
多主模式中的每个节点都会存储完整的数据,当数据增长达到硬件的最大容量时,就无法继续写入数据了,只能通过加大磁盘的形式进一步提高存储容量,但硬件也不可能无限制的加下去,而且由于多主是基于主从架构实现的,因为具备木桶效应,要加得所有节点一起加,否则另一个节点无法同步写入数据时,就会造成所有节点无法写入数据。
5. MySQL分库分表思想
根据业务属性的不同创建不同的数据库,不同的业务连接不同的数据库,各自之间数据分开存储,节点之间数据不会同步,以这种方式来部署MySQL,即提高了数据库的整体吞吐量和并发能力,同时也不存在之前的存储容量的木桶问题。实际上对项目做了分库分表之后,带来的问题、要解决的问题只会更多,只不过相较于分库分表带来的收益而言,解决问题的成本是值得的,所以才会使用分库分表技术。