一、背景

2023年03月08日，在某地域进行了线上压测，发现接口RT频繁超时，性能下降严重，P50 400ms+，P90 1200ms+，P99 2000ms+。

细致排查发现其中重要的原因是，访问缓存rt竟然飙到了1.2s左右。

作为高性能爱好者，榨干CPU的每一分价值是我们的宗旨，士可忍孰不可忍，怎么能光空转，不干活呢？那就仔细分析下问题。

二、为啥Redis访问延时如此高？

我们简化下Redis访问流程如下：

可能性1：服务端问题？

我们Redis使用的

redis_amber_master_4xlarge_multithread 16C32G+480G SSD 规格，最大QPS参考值24w，最大连接数3w，配置还是非常豪华的。

如下，QPS以及Load在峰值请求阶段，都仍然处于低位。

可能性2：物理网络问题？

如下，请求远远没有达到机器带宽，不是瓶颈，另外单独看了网卡重传率等指标也都正常。

可能性3：客户端问题？

那么很大概率就是客户端自身问题了。我们把客户端详细放大如下：

①JVM FGC STW？

根据当时ARMS监控结果如下，虽然YGC次数与耗时有所上升，但没有发生FGC：

②JedisPool问题？

把内存Dump出来，分析JedisConnectionFactory几个相关重要指标，发现问题有如下2个：

• maxBorrowWaitTimeMills过大：即最大等待时间过久。在等待从连接池中获取连接，最大等待了1200ms。很大概率是因为block在连接池获取，导致请求处理缓慢。

• Redis连接创建销毁次数过多：createdCount 11555次；destroyedCount：11553次。说明max-idle参数设置不合理（on return的时候检查idle是否大于maxIdle，如果大于则直接销毁该连接）。每个对象的创建就是一次TCP连接的创建，开销较大。导致脉冲式请求过来时引发频繁创建/销毁，也会影响整体性能。

顺便说一句：maxBorrowWaitTimeMills，createdCount，destroyedCount 几个metrics信息是JedisPool对象持久维护的全局变量信息，只要JVM不重启，这个信息就会一直存在。这也就是为啥不需要在压测峰值时获取内存dump，而是事后dump也可以。

此外，如果细致探索JedisPool参数工作机制，就需要了解apache的ObjectPool2的机制。刚好笔者在之前研究过ObjectPool，后续会出单独文章阐述&对比ObjectPool，ObjectPool2，JedisPool以及经常踩坑的DruidPool的实现原理与差异。

至此，定位问题是JedisPool行为异常导致。

三、如何解决问题？

线上JedisPool实际参数

部分参数是由 redis.clients.jedis.JedisPoolConfig 继承而来

spring.redis.jedis.pool.max-active=100
spring.redis.jedis.pool.max-idle=16


spring.redis.jedis.pool.time-between-eviction-runs-millis=30000


spring.redis.jedis.pool.min-idle=0
spring.redis.jedis.pool.test-while-idle=true
spring.redis.jedis.pool.num-tests-per-eviction-run=-1
spring.redis.jedis.pool.min-evictable-idle-time-millis=60000

参数行为解析

• max-active：连接池的最大数量为100， 包括 idle + active. 注意， 这里spring.redis.jedis.pool.max-active被映射为了ObjectPool的maxTotal参数上。

• 连接池的最大空闲数量为16，即如果return时，idleObject>=16，则该对象直接被销毁。

• 启动后台线程，每30s执行一次，定时心跳保活与检测。

• 连接池最小空闲的连接数量为0。即corePoolSize为0，不会长期maintain一个固定的容量。

脉冲式请求引发的问题

我们把问题简化为如下序列，即可发现问题所在。在T2~T3内，84个对象创建，84个对象销毁，造成了极大的损耗。

期望的行为模式

由于线上环境，Redis服务器配置较高，为了能充分压榨性能，同时应对容器场景下典型的突发峰值，因此如下行为：

• 连接池的最大数量=连接池的最小数量=连接池的稳定数量，即不要临时去创建连接，防止等待过久。
• 需要定时心跳保活与检测，及时删除掉超时/无效的连接。
• 不要因为idle时间过久而重建连接（只因为连接失效而重建）。防止无意义的大规模连接重建。

spring.redis.jedis.pool.max-active=500 // 线上稳定保有4台，4*500=2000，仍然远小于Redis规格支持的3w
spring.redis.jedis.pool.max-idle=50


spring.redis.jedis.pool.time-between-eviction-runs-millis=30000 // 定时心跳保活与检测


spring.redis.jedis.pool.min-idle=500 // 连接池的稳定数量
spring.redis.jedis.pool.test-while-idle=true //定时心跳保活与检测
spring.redis.jedis.pool.num-tests-per-eviction-run=-1 // 每次保活检测， 都需要把500个连接都检测一遍. 如果设置为-2， 则每次检测1/2比例的的连接.
spring.redis.jedis.pool.min-evictable-idle-time-millis=-1 // 不要因为idleTime大于某个阈值从而把连接给删除掉. 这样可以防止无意义的大规模连接重建。

四、效果验证

终于在20230413重新迎来了一波压测，流量模型与上次相同。结果如下：

• maxBorrowWaitTimeMills 下降比例接近 80%
• createdCount 也从之前的 11555次 下降到了 500次(即池子初始化的size)
• 业务侧整体性能也大幅提升，P50与P90均下降了将近60%，P99更是夸张地下降了70%。简直是amazing，完结撒花！~

作者丨寒亭

来源丨公众号：阿里开发者（ID：ali_tech）

dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn

业务驱动的微服务架构演进之路：以 DDD 为指导思想

最大的内卷，其实是OKR驱动

2023-09-04 11:36·dbaplus社群

去年5月，以善用OKR独步江湖的Google公司宣布将对 Google 员工的绩效管理方式进行改革——Google 开始使用一种名为 GRAD 的新绩效评估流程。据了解，这一调整主要是基于员工对谷歌繁琐且很有负担感的绩效管理体系不满，而做出的回应。

这个不满有多严重呢，一项对 Google 员工的调查发现：只有 53% 的 Google 员工认为此前的绩效评估流程是“值得花时间的”，另外47%的谷歌员工则认为过去涉及绩效管理的工作过于繁琐，浪费时间。这种不满和“薪资缺乏竞争力”一起，位列谷歌员工对公司最不满意方面的前两位。为了防止人才流失，又不打算全员涨薪的谷歌，只好选择优化绩效管理系统（启用GRAD），来缓解员工怨气。

一、从OKR到“中华田园KPI”

无独有偶，今年2月，字节CEO梁汝波在内部发全员信，称会将业绩目标制定和回顾的周期，从双月调整为季度。具体来说，就是把双月OKR改为季度OKR。梁汝波解释，这样做是因为字节现在大部分业务相对成熟复杂，双月变化不明显，因此回顾周期可以更长。

不管官方的说法如何，这两件事被不少职场中的管理人士解读为，被称为“内卷神器”的OKR，开始疲态毕现、“卷无力”。回顾OKR引入国内至今，从最初的神话吹捧，到沦落为被很多大厂人白眼嫌弃。其中最主要的原因，就是很多务实的打工人们，尝试体验OKR后，发现不但疗效远不如广告，而且还会引发新的问题。才会不断对其吐槽，并将其打上“中华田园KPI”的标签。

OKR(Objectives and Key Results) 全称“目标和关键成果”，是一套明确和跟踪目标及其完成情况的管理工具和方法。由Intel 将其作为一个管理工具孵化出来，接着被Google成功应用，并发扬光大。后来又被字节跳动引入国内并全面落地，引起其他大厂的效仿风潮，这也是为什么谷歌、字节两大巨头做出上述声明后，大家都会不约而同地联想到OKR的“式微和失宠”。

OKR作为一种主动式、粗颗粒的绩效管理方法，听上去似乎和当今的科技企业管理模式和逻辑非常契合，也曾受到张一鸣、任正非等大佬的肯定背书，但在实践中，这个号称“尊重员工创造性、不以考核为目的”的模式，却遭遇了非常多实实在在的挑战。

二、OKR是如何拖垮公司的？

1、对齐耗时

大家都知道，OKR的O是Objective，是目标，而理想的OKR的设置，又是自上而下和自下而上的结合。上级和下级之间O的联结，应该是对齐关系。

举个例子，到季度末，需要制定下一个季度OKR时，首先需要询问员工，从他的角度出发，认为自己下个月最应该做哪些事，以及在他心目中的目标和关键任务是什么。然后团队负责人再和员工沟通，从领导的角度，从整个团队的目标，以及对这个员工认知和了解，和这个员工反复梳理、讨论，进而确定下一个季度应该做的事情是什么，最终形成这样一个OKR。这个过程就是对齐的过程。

上下同欲，组织协同，这话说起来简单，做起来可没那么容易，而是一个相当严谨、耗时的过程。很多公司和团队层级中使用OKR的过程中，并没有反复梳理，斟酌，讨论，而是流于形式简单讨论一下，或者为避免被一次次打回来，就索性“以领导的意思为意思”，制定目标和计划，既不严谨也不合理。

而且，OKR对齐的动作，并非一劳永逸，有的时候还要和团队的“O”动态对齐，既烧脑又费时；更要命的是，如果团队中有“卷王”存在，把OKR写得洋洋洒洒、挑战性奇高，那其他人对齐的难度就更大了，有可能费了半天劲，还是没有真正对齐，只有伪对齐或对不起（齐）。

2、与KPI形成双倍考核

设置OKR的本意，是为了激发员工创新和活力，鼓励挑战更有高度的目标，而并不是要求所有结果都必须达成。

以OKR用得最好的谷歌为例：在谷歌，OKR最佳达成率在60%-70%，所有OKR的平均预期值一般在0.6到0.7之间（1分满分），并没有所谓的百分百完成；相反，如果得分过高，或者目标全部完成，则和得分过低一样，都意味着OKR在目标的设定上出了问题。

但在我们的现实操作中，却往往不是这个样子。不少公司在制定OKR的时候，也是不断鼓励员工制定有挑战的目标，也并没要求这些目标一定要完成。但在执行的时候却往往会反水变味，把“鼓励你完成”，偷梁换柱成“必须完成”。完不成就会成为你的一个“污点”，上级领导早就忘了OKR“不考核、不挂钩”的“承诺”，明里暗里拿着这个“污点”和各种绩效处处挂钩。

这对那些原本就有KPI压力，现在又来了OKR变现考核的打工人来说，变成了妥妥的两座大山，双倍考核。

3、老板“OKR暴政”

OKR适用，需要一个隐性的基本前提，就是老板要目光长远、思维开阔，员工积极性要能被充分调动起来，只有这样OKR才能有真正的用武之地。

但现实中的不少企业，老板不管公司人才体系的实际情况，不管有没有可以嵌套的企业文化，上来就想本着向OKR“要效益”。才成立两年、总共10来个人的公司，老板也敢一拍大腿，把O定为“业内最有影响力的xx公司”。下面员工的KR就只能配合老板的“野心”，写成“2个月内开通3个以上个人自媒体账号和短视频账号，宣传公司产品，累计点击量10w+”

老板看了觉得不花公司预算，心里窃喜，但还是鼓励员工步子再大一点，“3个账号有点少吧，应该5个以上，点击量最好定在20w+吧…”老板发话了，员工就跟着改吧，本来自己也是配合老板演出，随便写写，根本就做不到的事，还怕再加加码吗，没必要惹老板生气。

就这样，本来一个严肃的OKR设定问题，变成了老板淫威下的暴政和员工顺水推舟的附和，除了让OKR招黑，真没有任何意义。

4、生搬硬套OKR

OKR在谷歌用的风生水起，让字节的管理如虎添翼，但这不代表别的企业就能照抄这些大厂的作业，不管适合不适合，都把他生搬硬套到自己公司身上。

比如，OKR模式有一条必须遵守的重要原则，就是“及时沟通”。但如果一些企业的文化和氛围，就是浓浓的家长式作风，每个领导都以为自己高高在上，只习惯安排下属按自己指示干活，那么OKR所需要的有意义的沟通，就是不可能存在的。换句话说，在这个公司，推行OKR的基础也是根本不存在的。

如果不考虑这样的实际情况，贸贸然将OKR搬到自己公司推行，不光不会有积极效果，反而可能带来不好的负面影响。

5、OKR不可持续

国外一些大厂比如谷歌、微软，在制定OKR时，虽然每个月、每个季度都会总结，但并不以月或者双月来做项目的管理。一般都是半年、一年起做一次大调整。但在国内的环境就不同了，OKR与KPI最大的不同之处，就是强调快速迭代，外界的各种变量都可能影响到OKR，因此任务制定周期通常不是按年或是半年，而是两个月一次，有的甚至1个月1次。K哥就曾见过一家执行单月OKR的公司，他们的OKR一个季度调整了3次。

我还遇过某个VP级的企业高管，在双月开始时给团队设定了很不现实的“挑战”性目标，并美其名曰要有野心、要敢于突破。但临近双月结束时，这位高管才发现执行的情况和目标相差太远，最后竟然很“低调”地调整了OKR。虽然OKR可以变更，但这种不严谨不科学的作为，是和设立OKR的初衷完全背离的，也会让团队成员对OKR这套体系产生反感和不信任。另外，频繁调整OKR，也容易导致对最终目标的偏离。就像开车的时候，本应该直线行驶，驾驶员总是开10公里偏离一次方向，时间久了，就可能完全偏离目的地。

三、哪些企业不适合用OKR？

任何管理方法的引入，都需要考虑企业的实际情况。它需要的不仅仅是在理念上对新方法的认可,也需要企业内外部环境与条件的支持。如果条件不具备,盲目推行只会增加管理的难度,减弱实施效果。比如以下三种类型的企业，就不太适用OKR：

1、行业本身变化不快，按部就班就行

一些行业的市场环境相对稳定，市场变化不快，企业的竞争力也相对较稳定，此时，OKR可能不是最合适的目标管理方法。这是因为OKR需要制定较长期的目标，并使用关键结果来衡量目标的实现情况。如果行业环境相对稳定，企业可以使用传统的目标管理方法，如KPI、SMART目标法，就可以让企业运转得够有效，完全没必要增加管理成本和管理的复杂度。

2、不适合快速试错的行业，有时候失败是致命的

OKR方法强调快速试错和学习，可能适合于科技、互联网等领域的企业。然而，对诸如医疗、金融、航空等行业却未必适用。因为在这些行业，产品研发过程漫长,容错度低,试错空间有限，如果采用OKR,可能会在追求产品创新进度时,忽略质量与风险控制,造成难以挽回的损失。对于这些行业来说，失败可能是致命的，这绝对是OKR不能承受之重。

3、企业没有制度变革的基础

OKR能否落地，有两点非常重要，一是企业文化；二是人才体系。具有平等沟通、积极协作的企业文化，拥有强大自驱力、追求卓越的人才团队，是推行OKR必备的土壤。这是因为OKR需要企业内部有高度的透明度和合作性，需要员工之间相互信任和支持。如果企业缺乏这些基础，处处有高高的“部门墙”，OKR不但不会发挥积极作用，还有可能导致不必要的冲突和紧张。

K哥曾为一家家族企业提供过咨询服务，他们的二代掌舵人总觉得自己企业的管理制度比较土，曾试图引入OKR，我给他的答案是，可作为长远考虑，但不建议现在实行。因为他们是传统的家族企业，具有家庭企业典型的保守文化和组织结构，从企业文化到员工素质，都不具备引入OKR的条件。为追求所谓的现代化管理，盲目推行，反而可能影响企业的正常运营。

四、哪些企业适合使用OKR？

合理利用OKR，确实能为一些适配的企业带来实质的帮助，对于员工，能够清楚地认识到团队的当务之急；建立易于理解的具体目标，以及清晰的成败评判标准；对于企业，可以更好地了解自己的进展，优化策略，实现快速增长和团队协作。以下几种特点的企业，比较适合落地OKR：

1、互联网初创公司

这个阶段的企业，战略目标通常并不是特别清晰、需要不停摸索来确认企业的发展战略。OKR可以将目标与结果关联，既强化了企业的目标牵引作用，又可以通过阶段性复盘，确保大方向的稳定性和正确性，同时还能将优势资源聚焦重要事项上，减少宝贵的创业资源的内耗。字节跳动就是一个很好的例子，在它成立的第二年，就引入了OKR，全员推广使用，让他们的团队如虎添翼，更有战斗力。

2、创新型企业

创新型企业通常需要快速适应市场和客户需求，需要不断试错和学习。OKR方法强调快速试错和学习，因此适用于这种类型的企业。

通过制定明确的目标和关键结果，创新型企业可以更好地了解自己的进展，优化策略，快速适应市场变化。比如，一些互联网科技企业,OKR可以帮助它们快速确定新产品与新业务的发展重点,动态调整资源配置,更高效地推出创新产品。

3、项目启动型企业

一般来说，内部结构更扁平化的企业，更适合使用OKR，这样项目管理的目标，才不会因为层层分级而过于分散，增加对齐的难度，反而会因为不断修正而逐步收敛，再借由对过程的量化与公开，可以更高效地实现项目落地和推进。

4、变革中的企业

这一阶段企业往往打下了一定的基础，开始谋求从存量到增量的变革，需要“上下同欲”的整体配合、快速深刻的变革，来适应市场环境的变化。OKR更能引导团队深度思考，并在目标公开透明的情况下，帮助企业制定转型路径,推动战略转型与组织重塑。谷歌公司全面引入OKR，员工规模只有40人，这个阶段推行OKR，就跟谷歌渴望蜕变转型的内在需求有关。

OKR到底是可以帮助管理者，扫清顽疾窠臼的神器，还是大厂员工眼里的内卷神器、身上的又一个桎梏枷锁？也许并不是OKR自己决定的，而是要看谁在用，适不适合用，会不会用。这事既不能赶流行，也不宜不负责地大加批判。OKR只是一个工具，理性、全面、客观地看待，才是成熟的职场人、管理者，该有的态度。

作者丨Mr.K

来源丨公众号：技术领导力（ID：jishulingdaoli）

dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn

直播预告丨业务驱动的微服务架构演进之路：以 DDD 为指导思想

DDD作为应对复杂架构的设计方法论，在遗留系统改造、企业架构、研发效能提等方面都可堪大用，进而成为各大企业调整微服务架构的指导思想。

9月6日晚7点，来自去哪儿网国内酒店java开发工程师-朱浩曼老师将带来《业务驱动的微服务架构演进之路：以DDD为指导思想》的主题分享，详解DDD领域建模过程及核心思想，通过去哪儿网DDD实际案例，剖析落地战略战术设计。

• 主题：业务驱动的微服务架构演进之路：以 DDD 为指导思想
• 讲师：去哪儿网 国内酒店-java开发工程师 朱浩曼
• 时间：9月6日周三晚7点
• 地点：线上直播间/dbaplus社群视频号
• 直播地址：业务驱动的微服务架构演进之路：以 DDD 为指导思想