大家好 小弟是软工菜鸟

目前有个专案的需求是，会在一段程式逻辑中

对数据库进行多次读取或写入，中间牵涉到两张表以上

因为需要每秒执行这段逻辑至少2次，怕用mysql会影响效能，于是考虑用Redis来做

但有查到Redis执行命令，即使用multi exec也并非原子性

所以假设现在Redis有5行写入要执行，但是执行到一半服务器挂掉

会不会导致资料只写了一半的数据错误问题呢？

那这样的业务情况就表示不适合用Redis了是吗？

谢谢！

lua script?

很在意资料的正确性就还是应该用 RDBMS 才对，MySQL没那么废啦！有做读写分离吗？

multi exec不就行了？ 你从哪查到非原子性？

try catch?挂掉 rollback?

虽然服务器挂掉不是你的问题,但是你要有备案处理

redis cluster了解一下，并且memory db本来就没保证

感觉你要的不是Redis而是queuing system 像是rabbit mq或是Kafka 之类的

上千TPS再来担心吧

你的操作具体是什么内容，系统设计没有明确规格就没办法给你正确的解法，每一种场景都有他的tradeoff除非你的操作是mysql server memory cache装不下的资料，一定牵涉到实体硬盘读取加上每秒两次不间断而且否则你都是想太多直接mysql做就好了真的要计较得话即使是RMDBS都有可能在crash的时候资料没有完整写入硬盘导致你必须手动修复原子性是存在逻辑层的，在实体世界，任何硬件操作都有可能因为硬件失败失去原子性如果你不考虑硬件失败，那么直接用redis persistence todisk没有任何问题因为RMDBS也是帮你塞了一层memory cache在硬盘写入之前，写入之前就当机一样会出问题

rdbms有那么弱吗

你真的要求资料绝对的完整性那就是用queue把一个操作纪录到任何一种载体最简单就是DB，然后另一支程式根据queue把一些资料写到你需要的其他地方，再标示queue中的这个task已经被正确的写入到其他位置然后你可能跟同事或owner讨论完就发现你的场景根本不需要这么严谨，量也没那么大，直接mysql一秒跑两次就结案了，也假设server hardware error不会好死不死造成data corruption

你是yangog4ever的分身吗

一般AP/DB同一台应该不需要考虑这个问题,过度设计了

queue+1

哪那么烂，之前公司要取资料，一次就取一千万笔，每五百笔commit一次也没当

我怀疑你本身有问题

每张表的资料多少？索引怎么设？能不能分库分表？预算多少？即时性？ 为什么每秒两次？能不能用前端减少查询量？硬件规格？ 压力测试报告？不讲业务和环境，谈任何技术都是耍流氓

一秒两次 用MySQL没问题，做读写分离就好，写入包在一个 transaction里面

redis 可以做 lockhttps://0rz.tw/at3R1

每秒2次的频率为啥会担心MySQL影响效能？

RDBMS很强啦，基本schema有做好，读写node分离，再不行切table partition，可以应付90%以上的场景一个table几百万条record都不会是问题

一个table 几十亿都看过...

每秒两次…

...........

TPS 2 应该不用想那么多吧...

读取跟写入要分开讨论，写入有交易问题先确认是否允许dirty read