类似 redis 或者 memcache 使用的时候如果将 key 统一做 md5 处理有什么好处呢，
Nicolay · 2019-07-21 13:55:39 +08:00 · 14907 次点击这是一个创建于 1959 天前的主题，其中的信息可能已经有所发展或是发生改变。
第 1 条附言 · 2019-07-21 15:35:00 +08:00
或者 base64 处理，其实想问 key 长度一致是否有助于 redis 的内存管理，
 |
1
lihongjie0209 2019-07-21 14:04:52 +08:00
如果你想访问 user:* 怎么办
|
 |
2
NewDraw 2019-07-21 14:22:16 +08:00 via Android
一楼的说法完美的回答了这个问题。
数据混淆，防止泄密。 |
 |
3
insert000 2019-07-21 16:29:49 +08:00 via iPhone
如果是高并发访问，md5 计算，cpu 会成为瓶颈
|
 |
4
Lax 2019-07-21 19:01:46 +08:00
md5 冲突了怎么办？
base64 长度会增加，而且长度不一致。 |
 |
5
MeteorCat 2019-07-21 19:04:49 +08:00 via Android
不要总想这种骚操作，你每个请求还得加个 md5 过程
|
 |
6
v2nika 2019-07-21 19:10:30 +08:00
感觉没有必要, 用 redis 要有分表的概念, 不同业务放在不同表里面, 这样不会有前缀, 都用 id 当 key 就好了
|
 |
7
Hstar 2019-07-21 19:21:32 +08:00
建议看看 redis 的原理，搞懂 redis 是怎么做 hash map 的，就不会问这俩问题了。
|
 |
8
yidinghe 2019-07-21 19:33:27 +08:00 via Android
有其他的高效哈希算法，比如 murmur2，但哈希毕竟不靠谱，还是不要用。
|
 |
9
newghost 2019-07-21 21:40:04 +08:00
做过 redis 的二次开发，redis 就像一个数据结构存储数据库，本身是个大的 hash map 集合。
在设计时为了考虑集群，将 key 都做了 hash 处理，这样 key 的分布就比较均匀，比较容易做负载均衡， 将各个 key 对应到各个实例中。 如果不考虑集群，直接存成一个有序列表就好了，key * 的性能也不会像现在这么差。 |
 |
10
dafengchui 2019-07-22 10:22:36 +08:00
@MeteorCat #5 这不是骚操作,这是稍微商用点软件都需要考虑的问题,防止泄密,虽然是防君子不防小人.
|
 |
11
ebingtel 2019-07-22 13:51:12 +08:00
说实话，如果明文的 key 长度不太长的话，做 md5 加密，没任何意义……如果 key 长度比较长，可以用 md5 缩短 key 的长度
|
 |
12
oldmanong 2020-02-24 23:53:17 +08:00
首先你无法使用 redis desktop manager 了，其次运维要骂娘了
|
Select Language