标签：关系 触发事件 工作 操作 serve odbc 框架 估计 未来
在M系统里，使用的数据库是sql server或者mysql。
整个框架类似于事件驱动，根据当前的硬件信号+数据库状态，判断事件是否满足触发条件，有的话，触发事件执行动作。
这样的框架，需要对每个事件轮询，如果大部分事件不满足触发条件，会导致优先级低的事件在等待触发的延时较长。
相当于 判断条件-》执行-》判断条件-》执行。
其实在执行的时候，就已经知道了下一步的数据状态会更改成什么样子。
最低级的做法，是再创建一个一模一样的数据库，作为未来状态的数据库，那这样在执行的时候，就可以先更新未来数据库，并且同步查询下一个命中的事件。
两个数据库也实在不好维护。
最近在一个项目，尝试实现了一个内存管理数据的未来状态，暂且称为未来内存上下文吧。
前期认为这个未来上下文，还是能满足的，但受限于自己设计的这个上下文，保存的数据太少，相比于一个未来数据库的功能，差的太多。
也曾经考虑是否能用redis作为这个上下文，其实也可以，但与原来对于sql server 或者mysql的映射关系，要维护这之间的数据同步，也是不小工作量。
查过互联网架构的框架，网上对于redis同步关系数据库的内容也太少了，估计现在都是各家实现各家的，以后应该会有这类型的工具或者代码出现，但目前没有。
后来查到了sqlite，这东西跟关系数据库类型，几乎可以跟sql server 或者mysql无缝对接，而且占用资源也很少，只要使用sqlite的库，封装成C++，再封装成类似ODBC的接口，因为项目里对于sql server和mysql是用ODBC连接的。
具体做法：
1.每次启动时，从sql server加载数据，创建一份结构数据同步的sqlite文件，由于需要作为内存上下文的数据量不多，生成sqlite时间大约在1~2s
2.每次事件判断触发条件，查询数据时，都从sqlite中提取，满足触发条件后，立刻执行sqlite的更新操作。
3.等待事件执行完毕后，再更新一遍sql server和sqlite，因为有个别数据，需要执行后才可以得到，这部分的确有数据的差异，所以sqlite还要更新一遍，好在差异的地方不多，是可控的。
标签：关系 触发事件 工作 操作 serve odbc 框架 估计 未来
原文地址：https://www.cnblogs.com/shawnc24/p/9842761.html
