丁俊：京东商城K-V存储产品的演化之路

　　前面有提到，我们在持久化化存储的基础之上实现了分布式锁和配置服务。企业当中或多或少都有这种需求，最初如果说Redis/Memcached没有升级之前，可能更多基于数据库去做;或者说我的场景比较简单，就基于数据库去做。我在做一个任务的时候，先把这个任务打个标，在数据库里面标识这个任务是分配状态或执行状态。你做完任务后，你可能就去把它解锁，把任务标识为执行完成，打上标的数据不会被别的服务抢到。

　　这里其实可能就带来一个问题，假设打上标以后你的服务就挂了，谁来解?可能你会引入比如超时时间，一个定时的服务，去检测这些长时间在执行中的任务，将其解锁，让它重新可以交给别人去执行。另一种方案就是基于Redis/Memcached这种服务，如果你只部署了一个节点，我们知道进入Redis/Memcached都是异步的复制，如果你的锁服务加上以后刚好碰到了你的master“死”掉了，这把锁是不是意味着就丢失了?redis作者提出了redlock算法，通过去多个redis里面同时写个锁，类似于这种分布式的协商一样。这里面其实有一个问题是什么?如果说写入以后，你的服务“死”了，可能你就需要根据你的业务给它设一个超时时间。对大部分的业务来讲，其实我觉得是能满足的。当然一些比较严格的服务里面，可能会面临一个问题，就是我们这个时间设多长合适?如果你设的时间不是很合适，可能到这个时间以后，服务还没有执行完就过期了。

分布式锁流程

　　另外一种就是基于Etcd/zk的方案，它有心跳机制。这里面有一个场景，就是网络中断以后，临时节点不存在了，但是服务本身还在跑，那么它要不要中断?因为你没有终止的话，还是有可能发生重复执行的现象。这里我们提供了一些业务可选的方案，根据场景去配置。比如，我们可以是合理的超时时间+心跳机制，让这个时间可以续期，如果服务没有“死”，还在执行，就可以加时间;还有一个就是分布安全超时时间+报警检测，设比较长的时间，我发现一段时间以后没有执行完，就给那个业务去报警;还有一种就是心跳过期+回调，是保证你的任务是能够取消掉的。

　　然后是配置服务，基于刚才讲的，我们KV存储是多range的，一台服务器、一个进程有多个range服务，意味着它是多点的写入。在range分裂的时候，树型结构的深度是有限制的，防止分离时group分组被割裂。

　　混合存储的实践与挑战

　　下面给讲一下混合存储。我们希望能做到冷、温、热的三层存储，冷数据保存在持久化急群众。其中冷和温数据在同一个进程里面去解决，这可能就涉及到一个Key的淘汰问题，将不常访问的数据淘汰到磁盘。淘汰有很多种算法，比如LRU、HIT DENSITY等等，这时又面临一个问题，Key要不要从内存里删除?其实内存本身就是需要低延迟的场景，这里面又关联到第二个问题，如果Key删掉以后，在访问Key的时候需要去磁盘访问，这样会不会阻塞掉内存访问的其他客户端的请求，拖慢整体性能?还有一个问题就是，内存里面可能有一些大的数据结构，要不要把它淘汰到磁盘上去?淘汰以后可能就意味着一些功能的阉割，作为一个平台，可能有些功能没有办法阉割的，需要进行一个取舍。

　　我们目前的做法是，作为一个冷数据，是采用异步去访问的(如下图)。比如说我有A、B、C三个客户端，A客户端访问到的是一个冷数据，key保存在内存里打个标，然后它需要访问磁盘，我们暂时把这个请求再丢给一个队列，把这一个CPU线程给释放出来，去处理别的客户端的请求。如果在我们以前其实没有按这种方式，就会导致就是说我访问磁盘，比如说要50毫秒，可能整个后面的任务都被阻塞50毫秒。

　　下图这是一个冷热分离的访问流程，没有太复杂的事情。

　　还有一个就是混合存储，如下，这一块我们还在实践当中。

　　今天我大概就讲了这三部分的内容，内存存储、持久化存储和混合存储，希望能够给大家带来一些共鸣，谢谢。

（编辑：温州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!