摘要:方法,如圖總結(jié)因為灰度環(huán)境在公司內(nèi)網(wǎng),訪問量較小,相比方法,方法可以暫時解決灰度測試時的緩存問題。但是仍然存在風險。
1.生產(chǎn)與灰度數(shù)據(jù)緩存背景:php做web開發(fā),MVC,phalcon
原因:
service層獲取數(shù)據(jù),有新增數(shù)據(jù)字段;
controller層是通過redisCache調(diào)用service接口;
redisCache采用redis-file雙緩存結(jié)構(gòu),可能存在情況:redis-cache有效;file-cache有效;直接本地調(diào)用service,再寫進redis和file-cache中;
線上有個腳本會每隔1秒通過redisCache調(diào)用一次此service接口,并且強制刷新緩存(redis-file);
灰度環(huán)境和生產(chǎn)環(huán)境用的是同一套redis,而且必須這樣;
所以,這就造成線上的腳本不斷的從線上的service中取得數(shù)據(jù),并刷新的redis-file緩存中,從而造成灰度環(huán)境直接讀了線上緩存,導致灰度代碼的service變更沒有生效
嘗試解決:
灰度代碼:問題controller調(diào)用redisCache接口,有強制刷新參數(shù),將其置為false;
存在問題:這樣是恨不正確的做法,會把灰度的service數(shù)據(jù)強制刷新到redis-file緩存中,從而導致線上緩存出現(xiàn)臟數(shù)據(jù),這樣后果很嚴重!!
灰度代碼:問題controller中,直接調(diào)用本地的service,不走緩存;
存在問題:導致灰度環(huán)境的所有(此controller)請求直接打在mysql上,從而增加了mysql本身的風險。
(方法1、2,如圖)
總結(jié):因為灰度環(huán)境在公司內(nèi)網(wǎng),訪問量較小,相比方法1,方法2可以暫時解決灰度測試時的緩存問題。但是仍然存在風險。
(各位看官,有木有更好的解決方案?)
原因:
環(huán)境:php+mysql+phalcon,生產(chǎn)環(huán)境,mysql存在主從;
通過接口傳入A、B兩組數(shù)據(jù)并在一個事務(wù)中分別插入到A-table、B-table中,提交事務(wù),再更新A剛插入的一個字段;
更新通過phalcon的findFrist找到數(shù)據(jù) 剛才插入的數(shù)據(jù),更新字段,調(diào)用save;
// 示例代碼 ATable,BTable都是繼承phalcon的model $a = array("id" => 1, "testa" => "data"); $b = array("id" => 1, "testb" => "data"); // 插入數(shù)據(jù) $db->startTrascation(); $a_obj = new ATable(); $a_obj->id = $a["id"]; $a_obj->testa = $a["testa"]; $a_obj->save(); $b_obj = new BTable(); $b_obj->id = $b["id"]; $b_obj->testb = $b["testb"]; $b_obj->save(); $db->commit(); // 更新數(shù)據(jù),findFirst $update_a_obj = ATable::findFirst(array("id=:a_id:", "bind" => array("id" => $a["id"]))); $update_a_obj->testa = "new_data"; $update_a_obj->save(); // 這里就會出錯,因為這里findFirst走了從庫 // -----------------說明---------------------- // findFirst走從庫是項目本身在model層做的初始化 public function initialize() { parent::initialize(); $this->setReadConnectionService("db_r"); $this->setWriteConnectionService("db"); } // setReadConnectionService由phalcon底層提供
可參考phalcon-model源碼
總結(jié):1. 永遠不要認為主從同步;2.同一個mysql連接,不要出現(xiàn)既用主庫、又用從庫;
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://systransis.cn/yun/30396.html
摘要:導讀在今年騰訊云峰會上,開源技術(shù)同樣是一大亮點。此文是微票時代技術(shù)副總裁楊森淼在現(xiàn)場有關(guān)微票兒的實踐之路分享的實錄。 導讀 在今年騰訊云峰會上,開源技術(shù)同樣是一大亮點。作為開源技術(shù)的集成平臺,Cloud Native 專場給各家提供了針對 OpenStack 應(yīng)用以及背后填坑之路作深度探討的機會。此文是微票時代技術(shù)副總裁楊森淼在現(xiàn)場有關(guān)《微票兒的 Cloud Native 實踐之路》分...
摘要:導讀在今年騰訊云峰會上,開源技術(shù)同樣是一大亮點。此文是微票時代技術(shù)副總裁楊森淼在現(xiàn)場有關(guān)微票兒的實踐之路分享的實錄。 導讀 在今年騰訊云峰會上,開源技術(shù)同樣是一大亮點。作為開源技術(shù)的集成平臺,Cloud Native 專場給各家提供了針對 OpenStack 應(yīng)用以及背后填坑之路作深度探討的機會。此文是微票時代技術(shù)副總裁楊森淼在現(xiàn)場有關(guān)《微票兒的 Cloud Native 實踐之路》分...
閱讀 2194·2021-11-24 09:38
閱讀 3255·2021-11-08 13:27
閱讀 3095·2021-09-10 10:51
閱讀 3162·2019-08-29 12:20
閱讀 674·2019-08-28 18:28
閱讀 3470·2019-08-26 11:53
閱讀 2719·2019-08-26 11:46
閱讀 1527·2019-08-26 10:56