带过期机制的悲观锁和乐观锁本质上都属于可抢占的分布式锁，相当于是将paxos要解决的问题退化为单Acceptor，因此实现起来非常简单。可过期的悲观锁和乐观锁唯一的区别就是前者在申请锁的时候有可能申请失败，而后者申请锁时永远不会失败。两种方案具体的表现优劣跟业务需求有关，不论一开始选择的是哪一种，都非常容易切换到另一种。
我在示例中实现了一个简单的乐观锁，在提交修改的时候用一个lua脚本做原子检查就能简单实现。如果要实现带过期机制的悲观锁，需要保证应用层有简单的时钟同步机制，而且在申请锁的时候也要写一个lua脚本。
在应用层也做了对应修改，调用数据访问层API可以按如下这种方式调用。之所以用了RTTI，是考虑到有可能会改成悲观锁实现，在Dispose的时候会自动release lock。现在pure服务与impure服务对数据服务调用的接口是不一样的，我们甚至还可以基于这一点在底层做一些扩展，最典型的比如读写分离。当然，这些都是引入主从之后要考虑的问题了。
1 using (var structFstAccesser = await GetStructFstAccesser()) 2 { 3 using (var structSndAccesser = await GetStructSndAccesser()) 4 { 5 var fieldFst = await structFstAccesser.LoadFieldFstAsync(); 6 var fieldSnd = await structSndAccesser.LoadFieldSndAsync(); structFstAccesser.UpdateFieldFst(fieldFst); 11 structSndAccesser.UpdateFieldSnd(fieldSnd); SubmitChanges(structFstAccesser, structSndAccesser); ; 17 } 18 }
View Code
有了这样一个简易的锁机制，我们可以保证单redis实例内的一致性。
引入新的问题有了无状态服务的概念，我们的架构中就可以逐步干掉类似切场景管理这种单点进程。无状态服务是高可用的，也就是说，任意挂掉一个，仍然能持续提供服务。
整个游戏服务端理论上应该具有整体持续提供服务的能力。也就是说，随便挂掉一个节点，不需要停服。场景服务挂掉一个节点，不会影响其他任何服务，只是玩家短期内无法进行场景相关操作了而已。
而我们见过的大多数架构，处处皆单点，这完全不能叫可用的架构。有的时候一个服务端跑的好好的，有人硬是要额外加一个全局单点，而且理由是更容易管理，让人哭笑不得。分布式系统中动不动就想加单点，这是病，得治。判断一整个游戏服务端是否具有可用性很简单，随便kill掉一个节点，如果服务端仍然能持续提供服务，即使是部分client受到了影响，也能称为是可用的。
但是，现在逻辑服务具有可用性了，可是数据服务还没有具有可用性，数据服务依赖于一个redis实例，这个redis实例反而成为了整个服务端中的单点。
幸好，redis像其他大多数工业级缓存基础设施一样，已经提供了足够用的可用性机制。但是，在讨论redis的可用性机制之前，我们先解决一下数据服务的一个遗留问题，那就是如何构建一个可以扩展的全局数据服务。
4.2 数据服务的扩展
redis是一种stateful service，继续应用之前的CAP原则，redis是倾向于AP的。之后我们可以看到，redis的各种扩展，实际上都是基于这个原则来做的。
4.2.1 分片方案
定义问题
我们遇到的问题是，如果将数据服务定位为全局服务，那仅用单实例的redis就难以应对多变的负载情况。毕竟redis是单线程的。
从mysql一路用过来的同学这时都会习惯性地水平拆分，redis中也是类似的原理，将整体的数据进行切分，每一部分是一个分片shard，不同的shard维护的key集合是不同的。
那么，问题的实质就是如何基于多个redis实例设计全局统一的数据服务。同时，有一个约束条件，那就是我们为了性能需要牺牲全局一致性。也就是说，数据服务进行分片扩展的前提是，不提供跨分片事务的保障。redis cluster也没有提供类似支持，因为分布式事务本来就跟redis的定位是有冲突的。
因此，我们之后的讨论会有一个预设前提：不同shard中的数据一定是严格隔离的，比如是不同组服的数据，或者是完全不相干的数据。要想实现跨shard的数据交互，必须依赖更上层的协调机制保证，底层不做任何承诺。
这样，我们的分片数据服务就能通过之前提到的简易锁机制提供单片内的一致性保证，而不再提供全局的一致性保证。
基于同样的原因，我们的分片方案也不会在分片间做类似分布式存储系统的数据冗余机制。
分片方案解决了什么问题
相关文章
精彩导读
热门资讯
关注我们
