现在需要设计一个系统，常驻内存运行，每秒接收上万条数据，每收到一条数据，就要跟mysql中该数据的配置进行比较，判断该条数据是否异常，确定其状态，然后根据mysql中上次的状态将本次状态写入mysql，供web前台查看，这样每来一条数据就要读两次、写一次。对于这样的情况，有没有好一点的解决方案。目前想到的是先将数据库中所有的配置读到内存，在更改mysql中的配置时，系统再读一次修改项，但是对于状态，因为要查询状态，必须保证状态尽量是最新的。对于这样的情况，有什么好的解决方案。多谢各位大神指教！
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
主从mysql 读写分离。。在搞个cache层。。。鄙人一点见解这方便没什么经验######
必须被肯定的是你的想法，数据推送到APP上从内存中查是非常好的解决方案。至于如何同步更新有很多种方法，有主动侦听的也有被动推送的，相信你一定能找到符合自己的办法。
目前想到的是先将数据库中所有的配置读到内存，在更改mysql中的配置时，系统再读一次修改项，但是对于状态，因为要查询状态，必须保证状态尽量是最新的。这句话隐藏着玄机，“必须”保证状态“尽量”是最新的，如果你能接受“尽量”，那么其实就意味着你的业务是能允许一定的时差的。 ######那些因素都还没来得及考虑。我理解你的建议是，让server功能尽量单一，保证可靠性，配置管理、查询等从server分离。good idea###### @_binary_ 恩，maybe我理解错你的意思了：我理解你的方案是单独拉一台机器来做配置管理(configserver)。web(client) -> server -> configserver，如果我理解错你的方案了，请华丽丽的忽略我之前的说法，哈哈。###### @_binary_ 偶的观点是，如果数据不大的话，或者前置机不是很需要吃内存的话，可以考虑直接将数据同步到前置机的内存中。避免到单点server上查询（哪怕server是在内存中也是会有风险的）###### @_binary_ 啊哈，请问有考虑单点故障么？有考虑日常停机升级维护么？有考虑网络波动么？既然给自己定位一个高并发的系统，这些因素就必须都考虑上，否则会导致业务全面崩溃。不开玩笑的～这绝对不是简单的做个主备就搞定的事情，还考虑到服务质量控制（没错，你已经是一个C/S模型了）######这是server端程序，client只负责发数据。server负责比较、状态更新、查询等功能，一台就够了######try Mysql Memory Engine for your conf table
