[請益] Redis執行多行寫入問題

看板Soft_Job作者 (yangOG)時間9月前 (2023/08/01 11:09), 9月前編輯推噓7(9推 2噓 46→)
留言57則, 24人參與, 8月前最新討論串1/1
大家好 小弟是軟工菜鳥 目前有個專案的需求是，會在一段程式邏輯中 對資料庫進行多次讀取或寫入，中間牽涉到兩張表以上 因為需要每秒執行這段邏輯至少2次，怕用mysql會影響效能，於是考慮用Redis來做 但有查到Redis執行命令，即使用multi exec也並非原子性 所以假設現在Redis有5行寫入要執行，但是執行到一半伺服器掛掉 會不會導致資料只寫了一半的數據錯誤問題呢？ 那這樣的業務情況就表示不適合用Redis了是嗎？ 謝謝！ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.141.18.126 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1690859355.A.382.html
→
08/01 11:25, 9月前 , 1F
lua script?
08/01 11:25, 1F
→
08/01 11:27, 9月前 , 2F
很在意資料的正確性就還是應該用 RDBMS 才對，MySQL
08/01 11:27, 2F
→
08/01 11:27, 9月前 , 3F
沒那麼廢啦！有做讀寫分離嗎？
08/01 11:27, 3F
→
08/01 11:28, 9月前 , 4F
multi exec不就行了？ 你從哪查到非原子性？
08/01 11:28, 4F
→
08/01 11:31, 9月前 , 5F
try catch?掛掉 rollback?
08/01 11:31, 5F
→
08/01 11:58, 9月前 , 6F
雖然伺服器掛掉不是你的問題,但是你要有備案處理
08/01 11:58, 6F
→
08/01 12:32, 9月前 , 7F
redis cluster瞭解一下，並且memory db本來就沒保證
08/01 12:32, 7F
推
08/01 13:31, 9月前 , 8F
感覺你要的不是Redis而是queuing system 像是rabbit mq
08/01 13:31, 8F
→
08/01 13:31, 9月前 , 9F
或是Kafka 之類的
08/01 13:31, 9F
→
08/01 13:40, 9月前 , 10F
上千TPS再來擔心吧
08/01 13:40, 10F
→
08/01 13:45, 9月前 , 11F
你的操作具體是什麼內容，系統設計沒有明確規格就沒辦法
08/01 13:45, 11F
→
08/01 13:45, 9月前 , 12F
給你正確的解法，每一種場景都有他的tradeoff
08/01 13:45, 12F
→
08/01 13:47, 9月前 , 13F
除非你的操作是mysql server memory cache裝不下的資料，
08/01 13:47, 13F
→
08/01 13:47, 9月前 , 14F
一定牽涉到實體硬碟讀取加上每秒兩次不間斷而且否則你都
08/01 13:47, 14F
→
08/01 13:47, 9月前 , 15F
是想太多直接mysql做就好了
08/01 13:47, 15F
→
08/01 13:51, 9月前 , 16F
真的要計較得話即使是RMDBS都有可能在crash的時候資料沒
08/01 13:51, 16F
→
08/01 13:51, 9月前 , 17F
有完整寫入硬碟導致你必須手動修復
08/01 13:51, 17F
→
08/01 13:52, 9月前 , 18F
原子性是存在邏輯層的，在實體世界，任何硬體操作都有可
08/01 13:52, 18F
→
08/01 13:52, 9月前 , 19F
能因為硬體失敗失去原子性
08/01 13:52, 19F
→
08/01 13:53, 9月前 , 20F
如果你不考慮硬體失敗，那麼直接用redis persistence to
08/01 13:53, 20F
→
08/01 13:53, 9月前 , 21F
disk沒有任何問題
08/01 13:53, 21F
→
08/01 13:54, 9月前 , 22F
因為RMDBS也是幫你塞了一層memory cache在硬碟寫入之前，
08/01 13:54, 22F
→
08/01 13:54, 9月前 , 23F
寫入之前就當機一樣會出問題
08/01 13:54, 23F
→
08/01 13:56, 9月前 , 24F
rdbms有那麼弱嗎
08/01 13:56, 24F
→
08/01 13:56, 9月前 , 25F
你真的要求資料絕對的完整性那就是用queue把一個操作紀
08/01 13:56, 25F
→
08/01 13:56, 9月前 , 26F
錄到任何一種載體最簡單就是DB，然後另一支程式根據queue
08/01 13:56, 26F
→
08/01 13:56, 9月前 , 27F
把一些資料寫到你需要的其他地方，再標示queue中的這個ta
08/01 13:56, 27F
→
08/01 13:56, 9月前 , 28F
sk已經被正確的寫入到其他位置
08/01 13:56, 28F
→
08/01 13:57, 9月前 , 29F
然後你可能跟同事或owner討論完就發現你的場景根本不需要
08/01 13:57, 29F
→
08/01 13:57, 9月前 , 30F
這麼嚴謹，量也沒那麼大，直接mysql一秒跑兩次就結案了，
08/01 13:57, 30F
→
08/01 13:57, 9月前 , 31F
也假設server hardware error不會好死不死造成data corru
08/01 13:57, 31F
→
08/01 13:57, 9月前 , 32F
ption
08/01 13:57, 32F
推
08/01 14:03, 9月前 , 33F
你是yangog4ever的分身嗎
08/01 14:03, 33F
不是喔
→
08/01 15:20, 9月前 , 34F
一般AP/DB同一台應該不需要考慮這個問題,過度設計了
08/01 15:20, 34F
推
08/01 16:45, 9月前 , 35F
queue+1
08/01 16:45, 35F
→
08/01 17:01, 9月前 , 36F
哪那麼爛，之前公司要取資料，一次就取一千萬筆，每五百筆
08/01 17:01, 36F
→
08/01 17:01, 9月前 , 37F
commit一次也沒當
08/01 17:01, 37F
噓
08/01 17:52, 9月前 , 38F
我懷疑你本身有問題
08/01 17:52, 38F
→
08/01 18:15, 9月前 , 39F
每張表的資料多少？索引怎麼設？能不能分庫分表？預算
08/01 18:15, 39F
→
08/01 18:15, 9月前 , 40F
多少？
08/01 18:15, 40F
→
08/01 18:20, 9月前 , 41F
即時性？ 為什麼每秒兩次？能不能用前端減少查詢量？
08/01 18:20, 41F
→
08/01 18:45, 9月前 , 42F
硬體規格？ 壓力測試報告？
08/01 18:45, 42F
噓
08/01 18:56, 9月前 , 43F
不講業務和環境，談任何技術都是耍流氓
08/01 18:56, 43F
推
08/01 19:12, 9月前 , 44F
一秒兩次 用MySQL沒問題，做讀寫分離就好，寫入包在一個 t
08/01 19:12, 44F
→
08/01 19:12, 9月前 , 45F
ransaction裡面
08/01 19:12, 45F
→
08/01 19:13, 9月前 , 46F
redis 可以做 lock
08/01 19:13, 46F
→
08/01 19:14, 9月前 , 47F
08/01 19:14, 47F
推
08/01 19:30, 9月前 , 48F
每秒2次的頻率為啥會擔心MySQL影響效能？
08/01 19:30, 48F
推
08/01 19:49, 9月前 , 49F
RDBMS很強啦，基本schema有做好，讀寫node分離，再不行
08/01 19:49, 49F
→
08/01 19:49, 9月前 , 50F
切table partition，可以應付90%以上的場景
08/01 19:49, 50F
→
08/01 19:50, 9月前 , 51F
一個table幾百萬條record都不會是問題
08/01 19:50, 51F
推
08/01 20:13, 9月前 , 52F
一個table 幾十億都看過...
08/01 20:13, 52F
→
08/01 20:57, 9月前 , 53F
每秒兩次…
08/01 20:57, 53F
謝謝各位前輩回覆！會去找相關資料來看，目前還是選擇用一般關聯式資料庫來做 ※ 編輯: yangog (36.235.184.182 臺灣), 08/01/2023 22:19:02
→
08/01 23:35, 9月前 , 54F
...........
08/01 23:35, 54F
推
08/02 01:14, 9月前 , 55F
TPS 2 應該不用想那麼多吧...
08/02 01:14, 55F
推
08/02 07:42, 8月前 , 56F
讀取跟寫入要分開討論，寫入有交易問題
08/02 07:42, 56F
→
08/02 07:44, 8月前 , 57F
先確認是否允許dirty read
08/02 07:44, 57F
‣ 更多 yangog 的文章
文章代碼(AID): #1ao7TRE2 (Soft_Job)