OneProxy :: 抛弃读写分离,只有集群流量合理分摊,回归数据强一致性!

在实现强一制性读写分离功能后,继续实现了强一致性查询缓存(Query Cache),并在一客户场景升级进行实际考察,原本担心的读写分离效果,并没有因为强一制性而大打折扣,可以说效果非常理想。以后OneProxy不会再去宣传读写分离功能,而是要告诉客户只是集群的流理合理分摊(Load Balance),也让OneProxy从中间件演变身数据库集群(Cluster)软件。

在上图中第一行为Master节点,后面行为Slave节点,“T”开头的列代表实时的QPS,“Delay”表示只读节点的数据延时。在过去的这几天中,充分享受了新技术带来的好处,具体有以下几点:

  • 数据的一致性,改善了最终用户的感受,更新的数据马上就能看到,减少了用户的咨询量,让应用开发人员重新回归单机的研发感觉。
  • 充分利用了只读节点的处理能力,过去到一个时间点后只读结点马上没有作何流量,而现在可以继续服务没有更新的表的查询,更加合理地分摊了集群的流量,提高了资源的利用率,降低了写入结点的连接数(见上图中的实时QPS)。
  • 一致性查询缓存,使得开启查询缓存来优化系统变得极其简单,可以设置较长的缓存时间,以提升缓存的使用效率。
  • OneProxy层版本控制机制,既保证了读操作的强一致性,也使得只读结点的延时状况更为直观和真实(将灵敏度提升到毫秒级),并且不依赖于具体的底层复制技术(Replication, Semi-Sync,  MGR, 第三方复制等),无论底层是哪个MySQL分支(Oracle, Percona, MariaDB等),还是哪个MySQL版本(5.1, 5.5, 5.6, 5.7, 8.0 等),都可以轻松搭建MySQL集群。

此外在新版本中,还改进了后端连接池管理模块,由独立的线程来维护后端连接池,而工作线程将不再负责远程连接,可以确保消息的处理会比较及时,进一步提升集群总体性能。并且在默认情况下,所有的读都是强一致性的,但可以通过指示符(hint)的方式来进行非一致性读,第一种是彻底不管只读结点的时延情况,可以使用“slave”指示符,如下所示:

select /* slave */ ... from ...;

第二种方式是使用提示符指定当前SQL允许的只读延时情况,使用“delay”指示符(以秒为单位),如下所示:

select /* delay=10 */ ... from ...;

从业务系统中梳理出哪些可以不需要一致性读场景的工作量,要比梳理出必须强一致性读场景的工作量大太多了。OneProxy后续的重要改进目标是使它成为一个数据库的集群软件,而不是给开发留下各种各样的架构技巧,开发当和过去一样仅需要去关注业务,后端的事情就交给我们。

有过不少用户在几个开源项目中提出了这个功能需求,我们主动为客户考虑,已经提前做到了,不要忘了OneProxy同时具有分表功能SQL性能监控功能,只要你用,我们就能支持你,实现你的需求和想法。