分析下来,这不是用Redis能解决的缓存问题,而是历史数据的查询响应速度问题。
大家最开始是希望能够通过增加索引的方式解决,但是面对千万级别的数据量,大家也不敢贸然加索引,因为一旦数据库hang住,期间的所有数据库写入请求都会被放到等待队列中,如果请求是通过http请求发过来的,很有可能导致服务发生分钟级别的超时不响应。
虽然经常被用户投诉反应慢,也不能破罐破摔,直接超时不响应了吧。
于是大家陷入了两难的境地。
后来大家分了两个部分来优化持久层。
MySQL的主从配置
第一步就是配置MySQL的主从库,通过将读写请求分离,来提高数据库的响应速度。
从上图可知,来自同一台服务器的请求,经过MySQL-proxy被分流给了不同的MySQL节点,其中写请求给了主节点,读请求给了从节点。因此,大家首先通过分流的方式,减轻了单节点MySQL的响应压力,实现了优化的第一步。
引入ElasticSearch
但是,只配置MySQL的主从是远远不够的。
通过查阅论坛,相关资料,大家最终敲定在持久层引入ElasticSearch。
Elastic Search是一个轻量级的持久层工具,它支持动态多节点部署,自动备份,节点掉线后能够自动切换主从,动态广播发现新上线的节点,而这些优点的应用,无须修改任何server端配置。可以这样理解,如果你部署了4个elastic search节点,其中2个掉了,服务器还是可以很好的继续运行。
此外,它还有一个最重要的优势,那就是支持大数据快速查询。一张几千万的表,如果用MySQL查询,可能需要几秒到几十秒不等,但是如果用elastic search,只需要毫秒级别就能查询到结果。完美的解决了大家当前的问题,还顺带帮大家巩固了持久层的稳定性问题。
综上,优化Mysql的目的是为持久层服务,除了引入主从配置,当MySQL自身局限性导致无法继续优化后,引入其他技术也是十分必要的。
如果你对这篇回答有任何问题,欢迎在下方点赞,留言。
偶是苏苏思量,来自BAT的java开发工程师,头像是本人,每天都会分享科技类见闻,欢迎关注偶,与偶共同进步。