没有Redis服务，数据没地方放，存储问题真让人头疼啊

（来源：某技术论坛用户发帖）

“我这项目刚搭起来，就卡在数据存储这步了，本来寻思用Redis对付一下，速度快嘛，结果运维那边说服务器资源紧张，暂时不给装Redis服务，这下可好，我那点用户状态、临时缓存啥的，一下子没地方搁了，全堵在程序里，真是愁死个人。”

“最开始想的太简单了，觉得用程序里的内存变量存一下不就完了？比如用户登录了，我就把他信息放一个全局的Map里，key是用户ID，value是用户对象。（来源：开发者初期想法）结果一试，问题立马来了，服务器一重启，或者程序一不小心崩溃了，内存里这点东西唰的一下就全没了，用户正看着页面呢，啪叽一下就被踢出来要重新登录，体验差极了，这还不是最要命的，万一我以后想扩展一下，搞个多台服务器做负载均衡，那更乱套了，用户这次请求打到服务器A，登录信息存在A的内存里；下次请求运气不好，被分配到服务器B去了，B服务器根本不认识这个用户，又得让人家登录，这不乱弹琴嘛，用户非得骂娘不可。”

“没办法，只能考虑用数据库了，我们项目里倒是有个MySQL。（来源：无奈转向数据库的方案）可这玩意儿是干重活、存核心数据的，像订单、用户资料这些，我现在要存的都是些临时性的、不那么重要的数据，比如手机验证码、首页的热点文章列表缓存、还有用户最近的搜索记录，这些东西也往MySQL里塞，感觉就像用宰牛刀杀鸡，大材小用不说，还特别慢，每次读个简单的验证码，都得走一遍连接数据库、执行SQL、断开连接这套流程，跟直接从内存里取比起来，速度一个天上一个地下，而且这点鸡毛蒜皮的小数据，频繁地读写数据库，也给数据库平添了不少压力，我怕时间长了把主库搞慢了，那才是因小失大。”

“也想过用文件系统来存。（来源：另一种替代思路的探索）比如每个用户给他生成一个小文件，或者用一个大的JSON文件来记录所有这些临时数据，听起来好像挺简单，实际操作起来坑更多，首先就是读写速度，尤其是并发读写的时候，得考虑文件锁吧？不然数据很容易写乱套，然后又是那个老问题，如果部署多台服务器，这些文件该放在哪儿？放其中一台服务器上，其他服务器访问不到；用共享存储吧，配置起来又很麻烦，而且共享存储的性能和可靠性也是个大问号，想想都觉得头大，还不如不用。”

“这几天真是为了这点存储的事儿绞尽脑汁。（来源：开发者总结困境）Redis这类缓存中间件的好处，这回算是深刻体会到了，它就像是在高速的内存和笨重的关系型数据库之间，专门搭起的一个轻便快捷的‘临时仓库’，那些读多写少、要求速度高、丢了也不太要紧的数据，放在这里面正合适，既能享受到内存级别的速度，又解决了单机内存无法共享、数据易失的问题，现在没了这个‘仓库’，所有‘货物’要么堆在‘生产线’（应用内存）上碍事，要么就得塞进‘大型中央仓库’（数据库）里，折腾一圈才能拿出来，效率低下不说，还把整个系统的结构搞得特别别扭。”

“眼下看来，只能先凑合了。（来源：临时应对措施）把最最核心的、绝对不能丢的少量状态信息，还是硬着头皮往数据库里写，哪怕慢点也得保证一致性，至于那些丢了也能再生成的缓存，比如文章列表，就先在单机内存里存着，设置个短一点的过期时间，同时清楚地意识到一旦服务器重启缓存就失效这个事实，这终究不是长久之计啊，感觉系统像个跛脚鸭，跑不起来，现在就盼着运维那边能早点把Redis服务给安排上，或者能找到其他同样轻量级的替代方案，不然这颗‘定时炸弹’一直埋在这儿，心里总是不踏实。”