类似 redis 或者 memcache 使用的时候如果将 key 统一做 md5 处理有什么好处呢，

如果你想访问 user:* 怎么办

一楼的说法完美的回答了这个问题。
数据混淆，防止泄密。

如果是高并发访问，md5 计算，cpu 会成为瓶颈

md5 冲突了怎么办？
base64 长度会增加，而且长度不一致。

不要总想这种骚操作，你每个请求还得加个 md5 过程

感觉没有必要, 用 redis 要有分表的概念, 不同业务放在不同表里面, 这样不会有前缀, 都用 id 当 key 就好了

建议看看 redis 的原理，搞懂 redis 是怎么做 hash map 的，就不会问这俩问题了。

有其他的高效哈希算法，比如 murmur2，但哈希毕竟不靠谱，还是不要用。

做过 redis 的二次开发，redis 就像一个数据结构存储数据库，本身是个大的 hash map 集合。
在设计时为了考虑集群，将 key 都做了 hash 处理，这样 key 的分布就比较均匀，比较容易做负载均衡，
将各个 key 对应到各个实例中。
如果不考虑集群，直接存成一个有序列表就好了，key * 的性能也不会像现在这么差。

@MeteorCat #5 这不是骚操作,这是稍微商用点软件都需要考虑的问题,防止泄密,虽然是防君子不防小人.

说实话，如果明文的 key 长度不太长的话，做 md5 加密，没任何意义……如果 key 长度比较长，可以用 md5 缩短 key 的长度

首先你无法使用 redis desktop manager 了，其次运维要骂娘了