在M系統(tǒng)里，使用的數(shù)據(jù)庫是sql server或者mysql。

整個(gè)框架類似于事件驅(qū)動(dòng)，根據(jù)當(dāng)前的硬件信號+數(shù)據(jù)庫狀態(tài)，判斷事件是否滿足觸發(fā)條件，有的話，觸發(fā)事件執(zhí)行動(dòng)作。

這樣的框架，需要對每個(gè)事件輪詢，如果大部分事件不滿足觸發(fā)條件，會(huì)導(dǎo)致優(yōu)先級低的事件在等待觸發(fā)的延時(shí)較長。

相當(dāng)于 判斷條件-》執(zhí)行-》判斷條件-》執(zhí)行。

其實(shí)在執(zhí)行的時(shí)候，就已經(jīng)知道了下一步的數(shù)據(jù)狀態(tài)會(huì)更改成什么樣子。

最低級的做法，是再創(chuàng)建一個(gè)一模一樣的數(shù)據(jù)庫，作為未來狀態(tài)的數(shù)據(jù)庫，那這樣在執(zhí)行的時(shí)候，就可以先更新未來數(shù)據(jù)庫，并且同步查詢下一個(gè)命中的事件。

兩個(gè)數(shù)據(jù)庫也實(shí)在不好維護(hù)。

最近在一個(gè)項(xiàng)目，嘗試實(shí)現(xiàn)了一個(gè)內(nèi)存管理數(shù)據(jù)的未來狀態(tài)，暫且稱為未來內(nèi)存上下文吧。

前期認(rèn)為這個(gè)未來上下文，還是能滿足的，但受限于自己設(shè)計(jì)的這個(gè)上下文，保存的數(shù)據(jù)太少，相比于一個(gè)未來數(shù)據(jù)庫的功能，差的太多。

也曾經(jīng)考慮是否能用redis作為這個(gè)上下文，其實(shí)也可以，但與原來對于sql server 或者mysql的映射關(guān)系，要維護(hù)這之間的數(shù)據(jù)同步，也是不小工作量。

查過互聯(lián)網(wǎng)架構(gòu)的框架，網(wǎng)上對于redis同步關(guān)系數(shù)據(jù)庫的內(nèi)容也太少了，估計(jì)現(xiàn)在都是各家實(shí)現(xiàn)各家的，以后應(yīng)該會(huì)有這類型的工具或者代碼出現(xiàn)，但目前沒有。

后來查到了sqlite，這東西跟關(guān)系數(shù)據(jù)庫類型，幾乎可以跟sql server 或者mysql無縫對接，而且占用資源也很少，只要使用sqlite的庫，封裝成C++，再封裝成類似ODBC的接口，因?yàn)轫?xiàng)目里對于sql server和mysql是用ODBC連接的。

具體做法：

1.每次啟動(dòng)時(shí)，從sql server加載數(shù)據(jù)，創(chuàng)建一份結(jié)構(gòu)數(shù)據(jù)同步的sqlite文件，由于需要作為內(nèi)存上下文的數(shù)據(jù)量不多，生成sqlite時(shí)間大約在1~2s

2.每次事件判斷觸發(fā)條件，查詢數(shù)據(jù)時(shí)，都從sqlite中提取，滿足觸發(fā)條件后，立刻執(zhí)行sqlite的更新操作。

3.等待事件執(zhí)行完畢后，再更新一遍sql server和sqlite，因?yàn)橛袀€(gè)別數(shù)據(jù)，需要執(zhí)行后才可以得到，這部分的確有數(shù)據(jù)的差異，所以sqlite還要更新一遍，好在差異的地方不多，是可控的。

總結(jié)

以上是生活随笔為你收集整理的php mysql sqlite缓存_使用sqlite作为数据缓存的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。