有赞DB连接池性能优化
很多系统的优化最后往往是对 DB 的优化,比如索引优化、并发控制,但如果提前剧透本次优化过程,其实最终只调整了一个bit,并且性能几乎翻倍,猜测很多人会觉得这是标题党在吊胃口,说实话剧情如此翻转笔者也没猜到。 背景 应用 T 的数据库连接池使用了 druid 1.1.20 (https://github.com/alibaba/druid) ,在压测时碰到 DB…
Read More很多系统的优化最后往往是对 DB 的优化,比如索引优化、并发控制,但如果提前剧透本次优化过程,其实最终只调整了一个bit,并且性能几乎翻倍,猜测很多人会觉得这是标题党在吊胃口,说实话剧情如此翻转笔者也没猜到。 背景 应用 T 的数据库连接池使用了 druid 1.1.20 (https://github.com/alibaba/druid) ,在压测时碰到 DB…
Read More有赞发号器多机房方案 发号器一般用来产生全局唯一 ID,有赞发号器的设计及背景参见文章《如何做一个靠谱的发号器》,本文在此基础上进行扩展,提供多机房发号与集群拆分能力,下文中使用 March 表示发号器服务。 图1 展示了改造前发号器双机房的架构,其中:控制台负责管理发号器配置,March 包括主备节点,主节点负责发号,备节点进行灾备,etcd 作为持久化存储。 图1. 发号器架构 问题 根据图1 架构可以看出,…
Read More引言 想必本文的读者对数据库都不会陌生,由于数据库良好的特性和服务的稳定性,使得我们的工作几乎离不开,而数据库连接池因为连接复用的优势也被广泛的使用,但凡事不可能只有好处而没有代价,使用连接池一个最直接的代价就是需要配置一堆的参数。其实很多时候这个复杂度也不存在,只要找个工程把配置拷贝一份,改一下用户名密码也就能工作了,因为之前的配置都正常工作了一段时间基本也没问题了,这个逻辑本身没毛病,但有个前提至少知道配了什么,不然问题来了都不知道如何应对。本文以 druid 1.1.5 (https://github.com/alibaba/druid) 连接池为例来阐述几个参数的重要性及如果避免踩坑,…
Read More