mongo导出数据一闪而过
怎样改小游戏格式的？
怎样改小游戏格式的？
在游戏中, 配置和数据是分开的. 配置一般不会在游戏过程中改变, 但数据会不断变化.配置一般是策划配置的数值表, 这部分可以用Excel配置然后通过工具导出成游戏可读取的格式如JSON, 游戏启动后加载到内存中,然后就不会再变化.数据是指玩家产生的数据, 这部分都是做持久化存储的, 如Mongo/MySQL/Redis等, 不同的游戏有不同处理方式, 一般是玩家登陆后从持久层读取, 玩家关键数据变化/定时触发/登出等情况下, 写回持久层中.
为啥Redis/Mongo这么快，就不能直接替代mysql吗？
mysql、redis、MongoDB基本上在对应的业务场景中都会用到。习惯上，所有的业务数据都是需要“落库”的，这种“落库”指关系型数据库的数据写入，可以很直观的在关系型数据库的客户端进行查询，可以持久化到磁盘空间，因 mysql 开源稳定，满足业务需求，其成为互联网公司的最优选择。而 redis 经常在高并发的请求加速、优化用户体验中用到，普遍的做法是将数据库中的数据请求一次，放入缓存中，同时返回给用户，而修改数据库时对缓存数据进行清理，保障数据一致性。而对于mongoDB，我在业务中使用不多，但其可以高效存储二进制大对象 (比如照片、视频、消息等)，在业界得到了充分的认可。下面简述一下其各自的优缺点，仅供参考。
mysql，优点：体积小、速度快、总体拥有成本低，开源，提供的接口支持多种语言连接操作；支持多种操作系统；采用完全的多线程编程，线程轻量；鉴权体系完善。缺点：不支持热备份，但可通过binlog日志进行同步；不支持自定义数据类型；对 xml 支持不够良好，但此基本上可以忽略，目前很少见到 xml 的使用。
redis，优点：读写性能优异，选择的最大理由；支持数据持久化，支持 AOF 和 RDB 两种持久化方式；支持主从复制，可以进行读写分离；数据结构丰富；缺点：不具备自动容错和恢复功能，主机从机宕机导致客户端请求失败；主机宕机，宕机前有部分数据未能及时同步到从机，切换 IP 后还会引入数据不一致的问题，降低了系统的可用性；Redis 的主从复制采用全量复制，网络波动时可能进行全量的数据复制，对集群造成压力；Redis 较难支持在线扩容，在集群容量达到上限时在线扩容比较复杂。
MongoDB，优点：弱一致性(最终一致)，更能保证用户的访问速度；文档结构的存储方式，能够更便捷的获取数；高效存储二进制大对象 (比如照片、视频、消息等)；与其他的NoSQL相比第三方支持丰富；缺点：不支持事务操作；占用空间过大；成熟的维护工具较为欠缺。
个人感觉，redis 适用于数据变化快且数据库大小可预见（适合内存容量）的业务场景，其适合做关系型数据库的中间层。MongoDB 可以作为大数据对象 (比如照片、视频、消息等)的数据缓存层组合出一个必要的数据实体（灵活的 json 结构可以组合出复杂数据类型，又可以复制多台服务器），读取速度也快，高并发构建主从服务器无压力。
作者：夕阳雨晴，欢迎关注我的头条号：偶尔美文，主流Java，为你讲述不一样的码农生活。