看板 [ Soft_Job ]
討論串[請益] rds replication & cache 多問
共 4 篇文章
內容預覽： 開啟 | 關閉 | 只限未讀
首頁
上一頁
1
下一頁
尾頁
#4
Re: [請益] rds replication & cache 多問
推噓0(0推 0噓 0→)留言0則，0人參與, 最新作者popcorny (畢業了..@@")時間7年前 (2018/08/05 21:40), 編輯資訊
0
0
0
內容預覽:
其實你兩個問題是同一個問題. 不管是 cache 或是 slave 甚至是 client-side 看到的狀態. 只能說是其中一個 valid state 的值. 不能當作之後 transaction 發生時候的當下值. 想想看 ACID 在講什麼. A -> Atomic 每個一 transact
(還有535個字)
#3
Re: [請益] rds replication & cache 多問
推噓0(0推 0噓 2→)留言2則，0人參與, 7年前最新作者alan3100 (BOSS)時間7年前 (2018/08/04 01:42), 7年前編輯資訊
0
0
1
內容預覽:
user1 read. user1 下單搶座位001 and 得到訂單處理中之訊息 (通常是icon轉圈圈之類). *user2 read. *user2 下單搶座位001 and 得到訂單處理中. user1 得到交易成功. *user2 得到交易失敗. 通常不會用lock, 而是實際上整個流程都
(還有410個字)
#2
Re: [請益] rds replication & cache 多問
推噓0(0推 0噓 0→)留言0則，0人參與, 最新作者life1347 (黑人)時間7年前 (2018/08/03 14:38), 7年前編輯資訊
0
1
1
內容預覽:
就問題一的部分. 從文章中的描述看起來是需要 strong data consistency. 面對這種狀況有種可行的做法是採用 distributed lock. (可參考 https://redis.io/topics/distlock). 但負面效益是會降低 throughput. 流程大概是
(還有636個字)
#1
[請益] rds replication & cache 多問
推噓3(3推 0噓 19→)留言22則，0人參與, 7年前最新作者sean72 (.)時間7年前 (2018/08/02 14:19), 編輯資訊
0
1
0
內容預覽:
問題一. 如果使用memcache. 寫db的時候. 1. 先invalidate cache 再寫db. 2. 先寫db 再invaludate cache. 3. update cache 然後 update db. 4. update db 然後 update cache. 我以為這個動作有標
(還有1027個字)
首頁
上一頁
1
下一頁
尾頁