高性能 key-value 数据库 Redis 短期发展规划

     <p>刚刚<span>Redis</span>的第一作者@<a href="/misc/goto?guid=4958198414386886194" rel="nofollow" target="_blank">antirez</a>发表了一篇博文，对Redis的后续发展规划做了一个比较明确的描述。下面是NoSQLFan的简单翻译，关注Redis的同学不要错过。<img title="redis.gif" border="0" alt="redis.gif" align="right" src="https://simg.open-open.com/show/df5991d0a55d38143bb663aa71ace558.gif" width="90" height="90" /></p>    <h3>Lua脚本支持</h3>    <p>对于Redis嵌入Lua脚本执行，目前已经有比较清晰的思路，你可以在<a href="/misc/goto?guid=4958198415278756180" rel="nofollow">这里</a>看到具体的描述。实际上脚本支持的工作已经完成了一部分，应该会在下一个稳定版本中就支持。这里面你唯一需要关注的可能就是，一些命令可能支持时间会比较长的问题（关于这个话题目前我们在Redis的Google Group上已经有一些讨论了）。</p>    <p>脚本支持将会在2.6版本中加入，而我们会尽量在今年年底发布2.6的第一个RC版本。因为在2.6版本中还有一些其它功能，目前我还无法确定具体会支持的功能，但是我会尝试按时间驱动的版本发布方式，尽量会将脚本支持和其它计划中的东西都在稳定版中实现。</p>    <h3>Redis<span>集群</span>功能</h3>    <p>Redis <span>cluster</span> 是下一阶段最重要的功能之一，实际上你可以通过这篇文章了解到Redis集群的一些设计思想和实现功能。但有一点我需要说明，就是集群所支持的功能，不会超出单机所支持的功能。而且并不是单机的所有功能都会在集群中实现，特别是对于多个key值的操作。这部分内容正在开发，在可预见的情况下，会尽量保证这些功能的可靠性。</p>    <p>Redis 集群能够容忍一般的节点故障和网络故障。但是需要说明的是，这个一般的情况，只包括一小部分节点故障和小规模的网络中断情况。我们不打算通过最终一致性的方式来解决诸如大型的网络故障的问题。</p>    <p>Redis 集群功能和脚本功能同样重要，但是集群功能得在3.0版本才推出。因为相对来说，脚本支持实现上会更容易一些，并且对大多数用户来说，用脚本来实现定制化功能的需要也更强烈一些。</p>    <p>实际上你目前已经可以试玩一下Redis集群的功能了，但目前实现还不完善。可能还需要几个月的开发才能进入到beta版本，到时我们才会更进行更 精细的发进并最终发布稳定版。我们会尽量在集群功能足够稳定后再发布。因为Redis目前已经能够支持很多应用场景了，所以我们在集群功能上会非常谨慎， 尽量不会对原有功能造成不必要的影响。</p>    <p>当然，好的一面是Redis的集群功能在设计上非常简单。这让我们很有信心可以在花费一段时间后能得到一个靠谱的集群实现。</p>    <h3>Replication功能的<span>改进</span></h3>    <p>为了更好的实现Redis集群功能，我们需要对现有的Replication机制进行改进。比如我们会修改数据同步方案，使得主从连接出问题后，不 必总是把全部数据进行重传。当然，这可能会有一定的条件，比如连接断开的时间需要在一定范围内，并且能够通过某种机制识别到断开前数据同步的进度。简单来 说，具体实现方式就是在slave和master断开连接后，master还是会继续发送操作日志，这部分日志会被缓存起来，等slave再连接上 master的时候，我们再将缓存这部分操作日志传给它。</p>    <p>这个功能可能需要在3.0或者更晚才能发布。因为现在的方案虽然并非最完美的，但是对Redis集群功能来说可能也够了。</p>    <h3><span>持久化</span>方案的改进</h3>    <p>目前Redis支持两种方式的持久化，RDB文件和AOF日志。这两种都有各自的好处。目前还是不特别明确会如何进行改进，可能我们会将两种方式合 并起来，或者是对AOF方式做一次比较大的改进。比如可能不再需要在线的rewrite AOF日志（rewrite可能能够通过外部程序或者独立的Redis线程来完成）。</p>    <p>虽然目前改进方向不是很明确，但是从今年初开始，在这方面我们积累了很多不错的想法，我们会通过实验来找出最好的方案。</p>    <p>其实目前很多用户并不清楚通过AOF和RDB的方式，Redis也可以是非常可靠的，所以我们希望在用户理解上和具体实现上，都能够让Redis AOF都更可靠一些。就像目前成熟的SQL数据库一样。</p>    <p>这也是在集群功能后才会来做的事。</p>    <h3>进行一些内部改造</h3>    <p>我们打算利用现有的Pub/Sub机制来实现一些Redis内部的通信，比如key值过期，客户端连接/断开，对key值进行了操作等等事件。到时 我们能支持使用者结合Lua脚本扩展来实现这些功能。比如将所有过期的key值放到一个list中，或者实现一些需要客户端结合Pub/Sub才能实现的 功能。</p>    <h3>提供更精确的过期时间</h3>    <p>我们会提供毫秒级别的过期时间设置，目前过期时间只能精确到秒级，虽然对于大多数应用场景来说已经足够了。</p>    <h3>长数据的读写操作性能改进</h3>    <p>如果你看一下 ’slowset’ 这个分支，你可以已经发现我们正在做这方面的工作。需要说明一下，这里说的长数据，是指范围在100k到1MB之间长度。对于kb级别的数据，Redis目前的处理性能已经非常高了。</p>    <h3>其它小功能</h3>    <p>你可以看一下<a href="https://github.com/antirez/redis/issues?labels=feature+request&sort=created&direction=desc&state=open&page=1" rel="nofollow">这个新功能的list</a>，这里面有很多我们会实现的功能，这些功能比较小，就不一一列举了。</p>    <p>来源：<a href="/misc/goto?guid=4958198416746424707" rel="nofollow" target="_blank">antirez.com</a></p>    <p>文章出处：<a href="/misc/goto?guid=4958198417479246309" rel="nofollow" target="_blank">http://blog.nosqlfan.com/html/3405.html</a></p>