这是一个创建于 1939 天前的主题，其中的信息可能已经有所发展或是发生改变。
单台服务器
对接的硬件设备，它们处理数据很快，超过 300ms 就认为超时、重试。
我的订单接口要插入数据到 6 张表中，大概 1-3s，所以经常出现大量重复请求。
想到一个不成熟方案，先把请求缓存 redis 中，先返回结果，再异步处理数据。
但是如果 redis 丢失或者 redis 缓存失败，数据就彻底丢失了，不知道如何补救。
求教好的方案
对接的硬件设备，它们处理数据很快，超过 300ms 就认为超时、重试。
我的订单接口要插入数据到 6 张表中，大概 1-3s，所以经常出现大量重复请求。
想到一个不成熟方案，先把请求缓存 redis 中，先返回结果，再异步处理数据。
但是如果 redis 丢失或者 redis 缓存失败，数据就彻底丢失了，不知道如何补救。
求教好的方案
 | 1 zardly666 2020-06-23 08:48:45 +08:00 消息中间件就是做这个的呀 rabbitmq |
 | 2 Finest 2020-06-23 08:54:08 +08:00 如果单纯是插入 6 张表要 1~3s，我觉得应该从性能上入手，查找问题 |
 | 4 swulling 2020-06-23 08:54:24 +08:00 via iPhone redis 做高可用就行了，不丢不就完了。 简单点就主从同步，加一个监控避免从落后太对就够了。 |
 | 5 AngryPanda 2020-06-23 08:56:17 +08:00 via Android 同意二楼，你这写入速度也忒慢了 |
 | 6 crclz 2020-06-23 08:57:07 +08:00 消息中间件没毛病哦 |
 | 7 skymei 2020-06-23 09:02:06 +08:00 感觉可以考虑先优化现有的 sql,然后尝试改为异步 |
 | 8 sadfQED2 2020-06-23 09:02:41 +08:00 via Android 才 6 张表就要 1 到 3 秒？？你应该先研究下为啥这么慢 |
 | 9 allanzhuo 2020-06-23 09:03:44 +08:00 via Android 1 到 3 秒应该有可以优化的地方 |
 | 10 mixtbkig OP |
 | 12 thinkmore 2020-06-23 09:06:40 +08:00 可能人家楼主只能有一台服务器，上中间件不合适。还是想想优化业务逻辑 |
 | 13 heyjei 2020-06-23 09:12:46 +08:00 先别急着 redis 和消息中间件， 先按二楼的意见，看下为啥 6 张表而已，却要 1-3 秒？ |
 | 15 leaderhyh 2020-06-23 09:23:50 +08:00  1 首先考虑最简单的通过提升件来 tps 其次考虑优化业务逻辑, SQL 等, 可以通过压测找出性能瓶颈 是代码还是 SQL, 亦或是有其他的第三方请求 最最最后才考虑改成异步, 因为异步返回的是处理中的中间态, 你可能还需要提供一个查询业务处理状态的接口 如果确定改异步, 可以考虑在简单的验证后将请求体直接落库, job 异步处理即可 |
 | 16 JsonTu 2020-06-23 09:28:33 +08:00 via iPhone 先记录下哪里耗时严重，如果是代码逻辑，看能不能优化，如果单插入 sql 耗时用消息中间件吧 |
 | 17 qq976739120 2020-06-23 10:00:21 +08:00 1 1-3 秒.....你插入的是 excel 不是 mysql 吧.... |
 | 18 guanhui07 2020-06-23 10:22:07 +08:00 太慢了 1-3 秒 排除逻辑 只插入到 Mysql 要这么久 |
 | 19 ty89 2020-06-23 10:24:01 +08:00 好奇，如何实现插入需要 1~3 秒的，一般人写不出来这么慢的 sql |
 | 20 Alex5467 2020-06-23 10:35:52 +08:00 订单的有些数据与本次请求无关的只是记录数据的插入操作完全可以做成异步的，还得排查一下是哪里慢了，整个看是看不出来的。 |
 | 21 zhuweiyou 2020-06-23 10:59:17 +08:00 异步处理就行了，性能问题加机器。 |
 | 22 isnullstring 2020-06-23 11:44:28 +08:00 是不是说漏，插表不会这么慢，连带业务处理时间了？ |
| 23 mixtbkig OP @isnullstring 是的 插入挺快的 |
 | 24 securityCoding 2020-06-23 14:21:29 +08:00 没啥并发的情况下写操作一般不会有多少耗时 , 重点看看读的索引吧 |
| 25 securityCoding 2020-06-23 14:22:09 +08:00 从根本上解决问题的思路是异步化 , 就是楼上说的各种中间件 |
 | 26 tingfang 2020-06-23 14:31:02 +08:00 太慢了，先看看 SQL 有没有问题吧，redis 、RabbitMQ 异步这些可以先不考虑。 |
 | 27 axbx 2020-06-23 15:48:49 +08:00 先检查一下是哪个地方处理最耗时，能优化就优化，实在不行再上消息中间件。 |
 | 28 cfcheng503 2020-06-23 17:15:26 +08:00 弄个中间表不行吗 |
 | 29 Kili9 2020-06-23 18:27:42 +08:00 先从业务逻辑和 sql 上找问题. 优化业务逻辑, 哪些该异步的就改成异步处理. 最直接的方法就是加服务器,集群,中间件 |
 | 30 seakingii 2020-06-23 20:35:03 +08:00 先不要写入业务表，搞一套中间表机制，先保证数据能写入，处理逻辑放在后面。 |
 | 31 jimrok 2020-06-23 20:37:14 +08:00 先落临时表，再异步处理，最后推送确认订单 |
Select Language