性能优化的PDCA

PDCA方法论是一种结构化的问题解决方法，又称戴明环。它将任务按照顺序从计划到执行再到检查，再到改善行动，循环不止。PDCA的四个环节分别是Plan（计划）、Do（实施）、Check（检查）和Action（行动）。

在PDCA方法论下，首先需要制定具体的计划，包括确定任务、阶段目标、时间节点和责任人。然后进行实施，落地各项具体活动。接着进行检查，检查实际执行结果，找出正确和错误之处。最后，在行动环节明确下一步需要采取的措施，根据检查结果改进计划。PDCA方法论的优点在于不断循环下去，不断迭代，推动组织进入良性循环，不断发现新的待改进问题。针对这些问题，首先要进行根因分析，制定具体的实施计划。然后定期检查实施结果和预期目标是否一致。最后，对改进结果进行复盘，保留好的方面，纳入下一阶段的循环中，继续改进。使用PDCA方法论的关键在于明确目标，而不是简单定性问题。通过不断循环，才能不断提高业务，取得胜利。对于一个红包领取的案例案例，我们可以使用PDCA方法进行描述：1）计划(Plan)：针对用户领取红包场景下的TPS瓶颈，我们计划寻找瓶颈点，并持续优化以提升TPS。目前的TPS是50，目标是3000。2）执行(Do)：经过分析，我发现缩短数据库访问的加锁时间，并将悲观锁优化为乐观锁模式可以提升性能。因此我进行了相关代码改造。3）检查(Check)：使用工具进行并发测试后发现，TPS大幅提升至800。4）行动(Action)：然而，仍未达到预期的3000 TPS，因此我们回到计划阶段，寻找新的瓶颈点，继续优化。5）计划(Plan)：持续提升TPS。我们发现在MySQL服务器侧返回OK后，需要客户端发出提交指令，MySQL服务器再执行提交。这种方式会导致行锁无法释放，从而降低TPS。6）执行(Do)：为解决这个问题，我们采取commit_on_success&rollback_on_fail的方式，在更新执行完毕后，MySQL服务器直接根据affectrows来进行提交或回滚操作，这样行锁就能立即释放，从而提升了TPS。7）检查(Check)：再次进行并发测试后，发现TPS大幅提升至3000。8）行动(Action)：性能达到了4000 TPS，超过了目标（3000 TPS），本次优化任务完成。性能与其它非功能要素《持续架构》一书很好地介绍了性能和成本、可扩展性、易用性的关系，而性能和可用性直接相关。一般地，性能是指系统在一定负载下的响应速度，包括处理速度和吞吐量等指标；可用性是指系统能够持续正常运行，不间断地为用户提供服务的能力；数据一致性则是指系统中的数据在多个副本中保持一致的能力。在设计上进行取舍时，可以从以下几个方面考虑。数据一致性和可用性的取舍：在分布式系统中，为了保证数据的一致性，在进行数据更新时需要等待所有副本都更新完成才能返回响应，这会影响系统的可用性。为了提高系统的可用性，可以采用异步复制的方式，即在更新主副本后，异步地更新其他副本，这样可以提高系统的可用性，但会牺牲数据的一致性。数据一致性和性能的取舍：为了保证数据的一致性，可以采用同步复制的方式，即在更新主副本后，同步地更新其他副本，这样可以保证数据的一致性，但会影响系统的性能。为了提高系统的性能，可以采用异步复制的方式，但会牺牲数据的一致性。可用性和性能的取舍：为了提高系统的可用性，可以采用冗余设计，即在出现故障时可以自动切换到备份系统，这样可以保证系统的可用性，但会牺牲系统的性能。为了提高系统的性能，可以采用负载均衡的方式，将请求分摊到多个服务器上，但这样会增加系统的复杂度。数据一致性、可用性和性能的综合取舍：可以根据具体业务场景和系统需求进行综合取舍。例如，在高并发的电商场景下，为了保证数据的一致性和可用性，可以采用一主多从的架构，主库负责写入操作，从库负责读取操作，通过异步复制来保证数据的一致性。同时，为了提升性能，可以在读写分离的基础上，针对高并发读的场景进行分库分表，提升对应并发写的TPS。关于性能和其他非功能要素的取舍，这里举几个具体的例子。案例1 满足性能要求的同时放松强一致性，保障最终一致性。在支付平台的设计中，会对资金账户操作进行记账，确保账务一致。然而，当遇到热点账户问题时，更新同一个账户余额可能会引发并发写的性能问题。为解决这个问题，一般采取缓冲记账模式。先记录账务明细事件，不立即更新余额，而是按照时间（例如分钟或小时）异步批量处理来更新余额。需要注意的是业务限制，尤其是在入金场景中使用缓冲记账，因为出金账户会扣减余额，有可能导致透支。案例2 为了满足性能要求，考虑适当的数据冗余，虽然这会增加存储成本。以用户领取优惠券为例，优惠券的使用规则存储在券模版上。而用户领取优惠券的记录通常会按照用户ID分库分表来存储和查询。在查询用户优惠券是否满足支付条件时，需要涉及对券模版的查询。可以考虑将相应的规则数据冗余到用户优惠券表中，以消除对券模版数据的依赖。案例3 这是一个真实案例。在优惠券领取业务中，由于对预算进行了分片管理，通过一个路由规则将其路由到相应的子预算。然而，在日常非高并发场景中，我们有一个碎片合并的模块来转移合并后的预算。但是在秒杀场景下，直接禁用合并模块是更好的选择。因为为了保障用户的业务可用性要求和性能要求（返回的RT），我们宁愿对业务逻辑做一些取舍。没有花完的碎片预算只是没有最大化地使用，但没有超出预算。所以说，没有最好的设计，只有最合适的设计。设计即取舍。案例4 这是一个反直觉的案例。通常的情况是用户访问多、并发高；并发高意味着服务响应时间（RT）应该在几十毫秒或百毫秒之内，页面的响应时间不应超过1-2秒。但也有特殊情况，比如高管查看的经营分析报表，该报表的用户可能只有几十人，且并发很低，但对于性能仍有极致的要求，期望页面能“秒开”。常规页面一秒内打开也不难，但对于统计计算型的报表，涉及大量数据载入和指标计算，则并非容易。案例5 为了性能，可以牺牲可扩展性或增加耦合。某支付服务依赖于一个安全服务，而安全服务又依赖一个计算服务。通过性能压测，发现在极致要求下，安全服务调用计算服务的时间比较长。后来决定将这两个服务合并在一起，运行时进行本地调用，从而满足了提升支付服务性能的需求。总之，在软件架构设计中，需要在性能、可用性和数据一致性之间取得平衡，甚至在业务有损和扩展性方法之间也存在冲突。欢迎订阅右军墨问专栏：

性能优化的PDCA

相关推荐