我简单聊一下。工作背景：工作两年，一年电商经验，一年数据产品经验。两家大厂经验。
其实所有的工作 如果进行拆分的话 可以理解为：
1 、处理输入
2 、逻辑处理
3 、处理输出
那么这个地方呢 crud 主要就是在处理逻辑这个 stage 上进行的，所谓高并发 其实我个人感觉我们不妨把目光看到第一个个和最后一个 stage ，如果我们后台框架使用的是 dubbo 默认配置的网络线程池是 200 ，现在我们要面对场景的 qps 高于 200 如何进行处理呢，举个例子，我们现在对接三方直播平台，我们是一个电商，需要自动把库存信息同步给直播平台，那么我们仅仅 sku 的变动调用就大于这个这个值了，这就导致我们对外提供的其他服务别人在调用时会显示不可用，那么我们解决这个问题最简单的一个办法就是在处理输入的时候 可以实现通过布隆过滤器 根据比如店铺 id 或者商品 id ，过滤一部分数据，同时数据同步部分的逻辑直接进行异步处理，我们直接返回 true ，但是发送了一个库存处理消息出去，然后这个地方我们可以在深入，比如对消息的 offset 或者 publishtime 做监控，线上出现消息挤压我们应该提前做好对应的预案，同时我们也可以考虑进行一定程度的流量合并，比如如果库存是 6000 ～ 4000 从第一次调用的时候我们注册一个 5s 左右的定时调度任务（可以参考使用海豚调度），同时这个值加入 redsi 给一个 5s 的锁，这期间的同一个商品的库存变更不处理 5s 后由定时任务回调你，同时针对回调失败的情况自动落库，如果有海量同步失败的数据，就要继续考虑 mysql 中的数据要用 spark 或者其他方式同步一份到 hive 中，然后做 ETL 的处理 比如发消息给你的系统，然后系统中针对这种情况进行异常处理，后续在深入，比如可以在内部的这种数据平台上配置小时级别的监控，如果失败库中数据不为空并且自增 id 有变化则进行同步，并且记录最后一条同步的 mysql 记录中的自增 id 信息，然后自动进行 trigger 。
这样的话就是一套比较完整的方案，不同平台之间的 数据同步 类场景 我们都可以使用这种思路进行思考