問(wèn)題描述

團(tuán)隊(duì)準(zhǔn)備做一套系統(tǒng)，因?yàn)榭紤]到后期的高并發(fā)的問(wèn)題，所以想在開始階段就將 NOSQL 設(shè)計(jì)進(jìn)來(lái)。

不想把 redis 做的和memcached作用一樣，只是簡(jiǎn)單的緩存。想將 redis 設(shè)計(jì)成數(shù)據(jù)的中間層。大概流程如下：

讀取數(shù)據(jù)，如果redis中沒(méi)有，從SQL讀取然后放到redis里面并設(shè)置過(guò)期時(shí)間。修改數(shù)據(jù)（更新、刪除、添加），先直接在redis操作，這里可能涉及到處于業(yè)務(wù)邏輯考慮，在redis里面使用list作為索引的情況，在redis里面刪除、更新、添加，然后使用一個(gè)例如redis的訂閱發(fā)布功能實(shí)現(xiàn)的隊(duì)列，“異步”的更新 mysql

沒(méi)有太多的開發(fā)經(jīng)驗(yàn)，這樣做的目的就是為了讀取和寫入的分離，而且利用redis的優(yōu)勢(shì)，降低熱數(shù)據(jù)的讀寫造成的損耗。

有類似經(jīng)驗(yàn)的希望提出需要改進(jìn)的地方，或者這個(gè)整個(gè)就是個(gè)不好的方案。

- - - 3月12日更新內(nèi)容 - - -

今天又看了百度數(shù)據(jù)庫(kù)中間層的PPT，于是特意去搜索了dbproxy的相關(guān)內(nèi)容，思想中介紹說(shuō)是通過(guò)sql語(yǔ)句的MD5值匹配進(jìn)行緩存的選擇，這樣的問(wèn)題是很容易造成數(shù)據(jù)更新的延時(shí)。于是我又想到了我自己的方案，將 redis 和 SQL 數(shù)據(jù)庫(kù)搭配做成數(shù)據(jù)庫(kù)中間層，這樣是不是就可以迎合對(duì)數(shù)據(jù)實(shí)時(shí)要求很高的應(yīng)用了。

- - - 3月13日更新內(nèi)容 - - -

和評(píng)論中的 @魚丸粗面 討論了下 http://www.oschina.net/p/mysql-syncer 這個(gè)項(xiàng)目，這個(gè)項(xiàng)目更多的是通過(guò)首先更新到 Mysql，然后再根據(jù)Mysql的更新內(nèi)容去更新 其他數(shù)據(jù)庫(kù)例如redis。有一個(gè)問(wèn)題很明顯，就是高并發(fā)下寫入Mysql是個(gè)可怕的事情，所以我之前想到的是直接更新redis然后異步更新Mysql，最后將redis作為緩沖層。如下圖（來(lái)自新浪某PPT）

問(wèn)題解答

回答1：

感覺(jué)更新redis時(shí)將sql入隊(duì)列然后再操作。控制好邏輯即可。