因为这个时候客户端已经认为成功了, 但是实际上可能没有成功, 这样不就不一致了么?
比如如下场景, 有client, leader, follower1, follower2几个角色, 日志同步到follower1的时候, leader会认为日志已经同步成功了, 然后告知client, 但是这个时候leader挂了, follower1成为了新主, 它发现了日志还没有提交, 之后, 它不能直接认为是提交了吧, 如果是的话, follower2还没有同步日志. 如果不是的话, client端拿到的信息就有问题了.

这个原因充分说明了要项目驱动学习。
只有你知道具体的项目的场景，才可以决定自己这个锁怎么处理。
比如，你如果抢不到资源就必须等待，而且是同步请求，那么必须等待。
比如，你如果可以接受若一致，就可以考虑等待多久锁，然后放弃，记录日志或者其他补偿机制。
当然这个就类似于 ReentrantLock 里面的 tryLock 和 tryLock(long timeout, TimeUnit unit) 的区别

不设置等着被系统kill掉?

maxmemory 是redis认为的内存占用大小, 通过info memory命令查看, 也就是 used_memory
dir参数设置的是redis数据 + log + pid文件存储的默认目录

1. redis cluster 方案: 没有proxy, 数据分片之后, 可以访问集群中任意一个节点来确定要访问的数据在哪个节点, 是一种将存储和元数据管理放一起的设计, 实现较复杂, 出现问题不好排查, 在大规模集群+多地域情况下不适合, 因为会导致较高的网络通讯成本 + 脑裂等问题
2. codis: 好处是有完善的运维管理平台, 但是对redis源码有侵入
3. twemproxy: 不支持自动容灾 + 扩容, 同时官方放弃维护

以上都支持通过tag的方式将某个类型的key保存到同一个实例中

对, 官方不支持windows

BRPOP 针对的是一个消息只有一个消费者的场景, 类似AMQ的queue
subscribe 针对的是一个消息有多个消费者的场景, 类似AMQ的topic

短期内大量数据淘汰会消耗大量的cpu资源, 甚至会出现淘汰的速度跟不上写入速度的情况
因为redis是采用定期检测+随机抽样的方式来进行主动数据淘汰的

自己参考restbed 简单实现了一个, 支持g++3.4以上版本:
https://github.com/hongliulia...

自己先用 第三范式 分解 再跟据需求 合理地冗余一些字段。