惊了 redis 还能这样玩？？

[johnsneakers]

接手新项目，那个程序把 hash 当 MySQL 来用，给我说他们以前项目都这样搞。具体是：所有玩家的个人信息放在 user 这个 key 里面，hset user 10000 用户个人信息 json。 第一次见这样玩的 ，我太菜了，怎么给对方说都不听。

看了一些人的回答我开始懵逼了。也可能是我没说清楚，这里的场景是做持久化只是会定时落地，也就是说有 100 万用户，那么这个 hash 里面的 key 就有 100 万个，线上来同时来几万人也都是操作这一个 key。
难道我真的错了么，我一直的做法是一个 user 一个 key, 如: userInfo:{$uid}。

[th00000]

翻页

[laudukang]

还以为是新技能

[wpzero]

＠ darklowly 我赞同的，没感觉有啥问题。

[cokyhe]

看大家回复的内容，深深地觉得 redis 真是好东西啊

[alcarl]

mysql 都可以这样玩的，redis 当然也可以

[yufpga]

这么做是有原因的，首先一个好处就是节省内存，hash 这种结构会对内部数据进行压缩，因此能够有效的降低内存，另外好管理，清晰啊。另外 100 万个 key 放一个 hash 表算什么，再加一个数量级也不是什么事，而且别人也是这么干的。另外你的一个 key，value 确实不能太大， 但那不是只针对 hash 这种结构， 再说了你的一个 key，value 能超过 100k 么？

[yufpga]

redis 本身是单进程单线程的，针对“线上同时来几万人也都是操作这一个 key ”这个说法， 换成你那种做法也不会有什么优化。

[wayslog]

刚看到这个描述的时候，身为我厂 Redis 维护人员的我心中一惊。尤其在集群模式下，单节点热 key、大 key 是一个非常难治理的行为。我们与之做了很多艰苦的斗争。但是后来想想，楼主提的例子上可能是有原因的，历史原因或者什么的？？？
其实如果是非集群模式下，即使把 key 拆散也只是一个节点在接受请求，而不拆反而会节省内存，这一点大家说的都比较明白了。

但是，如果有一天天上掉馅饼各位的业务量暴增，这个地方几乎是 100%会成为瓶颈，而且无法通过增加 Redis 节点的方式简单的解决。所以楼上各位在写代码的时候就不看扩展性只注重功能性的么？

[wizardoz]

为什么是当 MySQL 用而不是当 PostgreSQL 用？

[fcten]

热 key、大 key 容易造成单点问题。但是既然“他们以前项目都这样搞”，那就说明业务量达不到性能瓶颈，根据不要过早优化的原则，这么做也没太大问题。

[ioth]

@ylcc 你嘴真脏。
我在这行 26 年，你这样的混不出什么人样的。