这是一个创建于 2411 天前的主题，其中的信息可能已经有所发展或是发生改变。
接手新项目，那个程序把 hash 当 MySQL 来用，给我说他们以前项目都这样搞。具体是：所有玩家的个人信息放在 user 这个 key 里面，hset user 10000 用户个人信息 json。 第一次见这样玩的 ，我太菜了，怎么给对方说都不听。
第 1 条附言 · 2018-05-08 01:01:06 +08:00
看了一些人的回答我开始懵逼了。也可能是我没说清楚，这里的场景是做持久化只是会定时落地，也就是说有 100 万用户，那么这个 hash 里面的 key 就有 100 万个，线上来同时来几万人也都是操作这一个 key。
难道我真的错了么，我一直的做法是一个 user 一个 key, 如: userInfo:{$uid}。
难道我真的错了么，我一直的做法是一个 user 一个 key, 如: userInfo:{$uid}。
 |
101
th00000 2018-05-08 19:54:01 +08:00
翻页
|
 |
102
laudukang 2018-05-08 21:00:44 +08:00
还以为是新技能
|
 |
103
wpzero 2018-05-08 23:16:38 +08:00
＠ darklowly 我赞同的，没感觉有啥问题。
|
 |
104
cokyhe 2018-05-09 07:41:09 +08:00
看大家回复的内容，深深地觉得 redis 真是好东西啊
|
 |
105
alcarl 2018-05-09 07:48:20 +08:00 via Android
mysql 都可以这样玩的，redis 当然也可以
|
 |
106
yufpga 2018-05-09 09:20:41 +08:00
这么做是有原因的，首先一个好处就是节省内存，hash 这种结构会对内部数据进行压缩，因此能够有效的降低内存，另外好管理，清晰啊。另外 100 万个 key 放一个 hash 表算什么，再加一个数量级也不是什么事，而且别人也是这么干的。另外你的一个 key，value 确实不能太大， 但那不是只针对 hash 这种结构， 再说了你的一个 key，value 能超过 100k 么？
|
|
107
yufpga 2018-05-09 09:40:53 +08:00
redis 本身是单进程单线程的，针对“线上同时来几万人也都是操作这一个 key ”这个说法， 换成你那种做法也不会有什么优化。
|
 |
108
wayslog 2018-05-09 10:43:40 +08:00  1
刚看到这个描述的时候，身为我厂 Redis 维护人员的我心中一惊。尤其在集群模式下，单节点热 key、大 key 是一个非常难治理的行为。我们与之做了很多艰苦的斗争。但是后来想想，楼主提的例子上可能是有原因的，历史原因或者什么的？？？
其实如果是非集群模式下，即使把 key 拆散也只是一个节点在接受请求，而不拆反而会节省内存，这一点大家说的都比较明白了。 但是，如果有一天天上掉馅饼各位的业务量暴增，这个地方几乎是 100%会成为瓶颈，而且无法通过增加 Redis 节点的方式简单的解决。所以楼上各位在写代码的时候就不看扩展性只注重功能性的么？ |
 |
109
wizardoz 2018-05-09 13:37:47 +08:00
为什么是当 MySQL 用而不是当 PostgreSQL 用？
|
 |
110
fcten 2018-05-09 13:57:08 +08:00
热 key、大 key 容易造成单点问题。但是既然“他们以前项目都这样搞”，那就说明业务量达不到性能瓶颈，根据不要过早优化的原则，这么做也没太大问题。
|
Select Language