mfsd

1、推送im服务怎么做的

• im服务使用的技术是sockjs，整个服务有预处理消息的MQ服务和路由发送消息的push服务组成
• push服务主要解决的问题
• 1、保持检测客户端的在线状态以及推送消息的准确送达
• 2、多实例环境下进行message推送时怎么路由消息到客户端连接的实例
• MQ服务主要解决的问题
• 1、接收业务服务的消息推送请求
• 2、群发消息的处理 2、订单粒度读写锁是做什么用的

3、订单系统的设计

• 主要从两个方面去做设计，一个是从需求出发，进行服务的划分，实现订单的流程处理；另外一个是从订单数据出发，做一些数据的处理划分
• 订单系统根据业务需求划分不同的服务，订单收单下单、订单调度、订单配送、订单回传、订单监控，商家模块
• 基础服务：用户、定位、商户门店、原单、骑手运力、区域运力、第三方配送、
• 预下单：对接业务系统接收订单，并且预先处理平台对订单的配送能力，
• 下单：从rabbitMQ消费消费订单数据，完成配送的下单操作。生成个订单数据，和订单各个订单任务
• 订单表的分表
• 将订单数据分为b端数据和c端数据，并做了冷数据和热数据处理（？）
• 热数据进行分表，b端数据是根据单号进行商家id，来源平台id分表；c端数据是根据配送单号真的骑手id进行分表；

4、保证订单系统不丢单

• 写数据库、接收和发送订单过程
• 1、关键逻辑不使用读写分离，避免同步异常导致后续流程订单反查失败
• 2、关键逻辑不使用查询缓存，避免同步异常导致后续流程订单反查失败
• 3、订单补偿不直接使用MQ，比如修改订单状态失败时通过消息队列补偿，中间件问题可能会引起丢单
• 4、处理消息时失败，需要重试

5、分布式事务

• 数据最终一致性设计主要使用两种方法实现，一种是通过接口调用实现实时同步操作，另一种是使用消息通道以事件响应的方式进行异步处理

• 系统优化

• 写数据库时，减小事务粒度，避免锁表，注意慢sql

• 关注数据异构的性能和稳定性，在网络抖动问题时也能稳定

• 幂等性

• 千万级订单系统

• 主要是数据库的问题，基本架构太过于依赖数据库

• 下单服务处理接单慢

• 数据库压力大

• 数据异构延迟高

• 缓存数据质量差

• 方案

• 服务拆分，接单服务独立、订单引擎、订单管道处理后续订单业务

• 双写和数据补偿的方式处理缓存，缓存添加过期控制数据量

• 具体方案

• 接单服务时，在事务中创建订单、和订单首任务（写缓存、减库存、发送订通知、其他流程）

• 接单服务的数据库使用一主多从，写入是随机写入任意数据库

• 订单任务有任务引擎生成并执行，再首任务执行成功之后插入后续的任务，需要注意失败的任务重试

5、秒杀系统设计

• 特点：
• 定时开始，流量大
• 相对于用户量，库存很少
• 业务流程相对简单，一般是下单减库存
• 设计出发点
• 系统隔离，不影响其他业务系统
• 技术隔离
• 前端，cdn缓存静态资源，秒杀开始时间由有后端控制，在秒杀快开始之前通过js发送到前端
• 请求接入，过滤海量秒杀请求，识别机器请求，做好限流工作
• 应用层，做好请求削峰；通过集群分担请求，通过缓存和队列减轻处理压力；注意超卖问题
• 数据库隔离
• 使用额外的表或者库，结束再同步到主业务系统中