https://segmentfault.com/a/1190000006805840php
背景:php作web開發,MVC,phalconmysql
緣由:web
service層獲取數據,有新增數據字段;redis
controller層是經過redisCache調用service接口;sql
redisCache採用redis-file雙緩存結構,可能存在狀況:redis-cache有效;file-cache有效;直接本地調用service,再寫進redis和file-cache中;segmentfault
線上有個腳本會每隔1秒經過redisCache調用一次此service接口,而且強制刷新緩存(redis-file);緩存
灰度環境和生產環境用的是同一套redis,並且必須這樣;
因此,這就形成線上的腳本不斷的從線上的service中取得數據,並刷新的redis-file緩存中,從而形成灰度環境直接讀了線上緩存,致使灰度代碼的service變動沒有生效測試
嘗試解決:this
灰度代碼:問題controller調用redisCache接口,有強制刷新參數,將其置爲false;
存在問題:這樣是恨不正確的作法,會把灰度的service數據強制刷新到redis-file緩存中,從而致使線上緩存出現髒數據,這樣後果很嚴重!!spa
灰度代碼:問題controller中,直接調用本地的service,不走緩存;
存在問題:致使灰度環境的全部(此controller)請求直接打在mysql上,從而增長了mysql自己的風險。
總結:由於灰度環境在公司內網,訪問量較小,相比方法1,方法2能夠暫時解決灰度測試時的緩存問題。可是仍然存在風險。
(各位看官,有木有更好的解決方案?)
緣由:
環境:php+mysql+phalcon,生產環境,mysql存在主從;
經過接口傳入A、B兩組數據並在一個事務中分別插入到A-table、B-table中,提交事務,再更新A剛插入的一個字段;
更新經過phalcon的findFrist找到數據 剛纔插入的數據,更新字段,調用save;
// 示例代碼 ATable,BTable都是繼承phalcon的model
$a = array('id' => 1, 'testa' => 'data');
$b = array('id' => 1, 'testb' => 'data');
// 插入數據
$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();
// 更新數據,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底層提供
總結:1. 永遠不要認爲主從同步;2.同一個mysql鏈接,不要出現既用主庫、又用從庫;