我在公司的主要工作是负责xxx项目的研发工作，在其中我主要负责订单系统。
1）C端主要生成订单后，提单-支付-出库-自提/配送-订单完成-售后的全流程开发
2）消息中心主要负责监听订单的提单、拆单、支付、出库、完成、售后等消息
3）我作为订单域主研发，完成了xx项目订单中心从0到1的构建，先后完成了订单中心下沉、多业务线订单重构、订单消息中心构建，并支持了订单相关系统-会员中心、任务中心、nps订单调研问卷系统、餐饮点餐系统的交付。
4）主要技术 Springboot+mysql+es+ck+redis+react(c端)+vue(b端)
5）系统亮点：
- 兼容了线上线下两套订单数据(门店自提(自有数据订单)、配送(订单中台订单))
- 自建订单消息中心,可通过页面配置控制消费topic、mq消息限流、订单来源
- 代码兼容性强，通过订单打标适配不同业务线逻辑，一套代码先后支持了4套内部类似小程序的订单业务，1套跨子集团小程序订单业务
6） 系统难点：
-
业务复杂，字段多(上百个字段超大结构)->区分业务域，通过配置化返回不同字段，根据业务分库，根据时间分表
-
高并发，单topic订单消息并发量最高4-5w qps，十几个topic需要处理 -> 区分业务域进行消息过滤+转发，数据库也根据业务分库，根据不同业务库的规格和并发压力，配置不同的mq限流；对数据量大的库表，根据订单号/用户id进行分表；读写分离、主从分离（会有几十毫秒轻微延迟，会设置缓存，页面上先改状态，再将缓存数据同步到数据库，设计中间状态类似"支付中、订单暂停、取消中"状态）；
-
涉及到奖励发放逻辑比如发券、发豆逻辑，业务比较重要，一点问题就可能造成客诉、资损 -> 这类消息处理不再进行mq重试，防止超发；处理失败/异常，更新数据库对应状态为发放中/发放失败，后通过监控预警系统和数据补偿任务进行资产的补发