分类：场景设计

写在文章开头 针对既有场景设计和架构这个话题，一直是笔者近几年的工作课题，也一直想写，但是没有时间。还好，最近因为个人一些原因刚刚好需要针对这些场景进行一下复盘。而这篇文章正是基于上一篇starrocks架构优化前所遇到一个存量问题，即一个分布式架构下各个软件中间件局限性所导致的数据一致性问题。 同

写在文章开头 近期和读者聊到了一道大厂面试题： 有一个库存为n的商品，用三个线程进行库存扣减及三个线程进行库存补给，如何设计？ 借着这个问题，笔者就从一个设计者的角度聊聊并发编程的设计技巧。 (https://qiniuyun.sharkchili.com/202404212229302.png)

基于RocketMQ重构seata AT模式分布式事务 问题说明 我们核心的企业短信发送服务接入主要是用于处理各大企业的短信请求的，整体来说业务逻辑为： 1. 创建短信任务，存任务根到本地库(当前服务) 2. 日限扣减，扣减企业用户本日限额短信数(网管服务) 3. 短信发送，调用调度服务将短信提交到

大文件数据导入 需求 针对报备的企业，集团每日会将数据传输至文件服务器上，由本平台程序进行定时采集入库，这些文件的特点是： 1. 每日 1h 投放一份增量文件。 2. 文件最多可能有 15 个 3. 15 个文件中可能存在文件重复的情况 所以我们要做到： 1. 尽可能1小时内完成采集入库，如果失败要

@ toc 排查与定位因Spring拓展点使用不当导致RPC调用偶发错误问题 故障说明 在微服务设计拆解之初，因历史原因配置信息表和群发平台分到了不同的数据库上，因为业务上的需要群发平台的企业实体信息配置需要依赖于维测控制台的实体信息配置，由于涉及的join查询众多，所以考虑的开发成本和 RPC 网

@ toc 缓存置换失效问题 故障说明 本人负责的短信调度中心是负责发送短信的，在设计初期为了考虑到短信重发的场景，我们采用的 redis 来缓存已经发送的短信数据，只有明确短信发送且成功后，我们才会将其发送出去。 (https://qiniuyun.sharkchili.com/img0fba9c

@ toc 对ElasticSearch了解多吗？有参与哪方面的工作？ ES 这一块我们主要是做一些故障短消息和一些群发任务的检索的，整体来说 qps 量也不是很大，着重是需要考虑检索性能以保证某些故障情况下，短信详情可以快速被定位到，我在这其中主要是负责： 1. 配合运维进行ES服务器和分片设计的

@ toc 并行流线程池抢占 问题现象 统计中心基于各种统计收敛任务，有个统计中心任务是将文件服务器的任务通过去重后进行批量入库，日常情况下 5000w 左右的数据差不多在33min就能够处理完，对应的代码长下面这样： 但是在某次割接之后发现每次的处理性能变为50分钟至1小时，导致很多活跃端口数据未

@ toc 半包粘包问题排查与优化 历史背景 在进行调度中心重构的时候，我们走查了老版本的调度平台的代码，是典型的 BIO 通信模型架构，错误复杂的线程交互和一些比较老旧的并发容器使得这套调度系统性能表现非常差劲。在硬件指标和数据库负载正常的情况下经过压测，差不多可以稳定每秒发送 500 条数据。

@ toc 企业短信分库分表设计(重点简历提及) 需求说明 我们针对两个维度的短信介绍一下群求先来说说群发短信，这个是集团内部的短信，短信是一对多类型，一个任务最多可以建立 200w 条短信，每日差不多最多 2000w 条短信发送。 还有一种是属于企业级的短信，一对一的大部分就像是验证码、电商活动类