为什么要用网格计算？
最近一直在从事分布式运算的开发，使用了一些相关的中间件产品，前一段时间，在这里贴了一些基于ICE的基础文章。那么，今天就来具体讲讲ICE的Grid是一个什么概念吧。我觉得要了解Grid，就必须了解网格到底是一个什么样的东西。网上有很多文章介绍分布式，也有很多人在鼓吹各种云计算，那么到底什么是云？在技术层面如何理解云的内部机制？讲到实际的却很少，我不喜欢文章里充斥着各种无聊的技术名词，缩写或者晦涩难懂的语句（在我看来没事写这些名词的人要么不想真正教别人，要么自己都没搞明白自己想讲什么。），所以，我尽量用通俗的语言来解释。不过，毕竟是一种技术上的介绍，所以建议读我以下文字之前，尽可能的了解一下ICE是如何运作的。我写过一些相关文章，你可以在这个版面搜索ICE标题的文章，在这里不再重复解释。我这篇文章主要就是在这里说一下我对云的理解，以及在技术上的一些实现手段。当然，ICE不是实现云的唯一方法，现在开源和不开源的中间件，网格计算产品非常多，不过无论怎么变，其实都是为了解决几个核心问题的，把握好这几点就可以了。
前两天写了一篇关于《多级缓冲的服务器数据服务机制实现》，有些朋友问如何利用它实现分布式，还有就是它到底和memcached有什么不同？于是我补充了一张流程图，来说明我的实现机制。memcached实际是一种提供key-value的分布式存储系统，因为在分布式计算中，我可以设想把我的所有相同的计算节点，分不到不同的服务器上。举个例子，假设我的服务非常的好，有1000万人同时在线，他们都在互相给对方发送信件和邮件，那么我一台服务器的话，肯定承受不了这个数据量，那么怎么办？于是我提供一个发送消息的接口，比如这样（伪码）:
bool sendMessage(nSelfId, nTargetId, strText);
我希望，我有50台服务器，每个上面都部署上这样的接口，这样，1000万数据请求就可以分布在50台服务器上进行并行操作，这样我就大大提高了处理消息的效率，因为实际处理逻辑都是一样的，唯一不同只是数据的不同。但是，要命的是，我虽然可以部署50台服务器，但是数据中心只有一个啊！就算我分布了50台服务器处理好了并行入口的问题，一个数据中心也会成为我的单点故障源，万一崩了，我的前50台服务器完全就变成了摆设。还有，50台服务器链接一台数据服务器也是不可想象的，我好不容增长的并行效率，完全在这一个节点消耗殆尽。那么，我怎么办？
对，怎么办？不知道你是否听说过最近几年比较火的一个名词，叫做NoSQL。什么是NoSQL?其实这个名词含义比较广泛，简单来说，是从DBMS发展而来的，为什么这么说？请听我道来。
以前做应用，我们存储数据的时候，一般要建立一张或者几张表，比如：我建立一个表，里面有如下几个字段:
ID 名称 性别 最后登录时间 粉丝数量
1 freeeyes 雄性 2011-05-26 0
2 winston 雄性 2011-05-26 1000000
3 Baste7cat 雄性 2011-05-26 1000000
4 wildfire 雄性 2011-05-26 1000000
5 modern 雄性 2011-05-26 1000000
好，以上这几位都是我的服务对象（名字相同纯属巧合，请勿对号入座，哈哈），他们个个可都不好伺候。winston说，我要发布给我所有的粉丝一封邮件，告诉他们每人必须缴纳每月500元粉丝入会费，否则不给当粉丝的机会（黑社会啊）。Baste7cat的粉丝每天希望拜读7cat的最新深笑话故事，wildfire的粉丝们更关心wildfire身边的美女团又有什么新动向。modern又发布了一个挑战消息，敢于和他PK的人请排队预约。那么，我的服务器要达成这些服务，必须从数据库里面使用SQL语句一点点的把相关的数据查询出来，然后写入相应的消息。不过，上帝，要知道，他们每个人都有100万个粉丝，就算我服务器再快，完成这些事情也需要N久。另外，如果的服务器如果在服务此过程中，因为各种原因，系统断电，内存挂掉，CPU过热等等，导致服务器崩溃，那么我的这项工作完成与否，完成到什么程度就不得而知了。
好家伙，winston立刻找我来，说，你这是什么烂系统，慢我也就忍了，崩溃了，造成我的消息没有完整的传达到我的粉丝上！你的罪责可大了，要知道我为此少收了多少钱吗？你赔得起吗？赔不起就让我的兄弟们找你约谈一下吧。。。
于是惊恐的freeeyes准备改进自己的系统，既然一个数据库太危险，那么我就放在10台DB上，每10万个用户在一个DB上。哈哈，10台同时崩溃的几率小多了。系统稳定性得到了提升。winston大神总算对付走了。
看似问题得到了解决，结果发现问题又来了，wildfire来找我，和我说，我需要给指定的粉丝发送一些消息，然后给另外一些指定的粉丝发送一些别的消息。你来给我改一下吧。freeeyes倒抽一口凉气，好家伙，以前我只对一台DB做代码工作，现在我要对10台DB进行遍历，自然比一台DB慢的多，而且，有可能wildfire的粉丝在这10台DB分布是不平均的。有些服务器可能很轻松，只有几条，有些则很累，有几十万条。完了，系统设计出来以后，有的服务器慢，有的服务器快，造成了更大的负载不平衡。比我原来的单一DB设计还慢。
Baste7cat立刻拍着桌子来找freeeyes，你为了满足wildfire的需求，结果无辜的把我给粉丝的邮件也拖慢了，凭什么我要为他的行为买单？你得给我解释！否则我不干了！
没办法，还有什么好的想法？可怜的freeeyes已经把DB拆分了，但是无法解决数据热点的问题（有的服务器冷，有的服务器热）。那么，我有没有方法，来平均分布数据热点呢？后来freeeyes发现，DB强大在于数据关系的存储(DBMS)，而在某些应用条件下，我是否需要这么严谨的数据关系来满足我的需求呢？我需要的只是保存一个明星和一堆粉丝的存在关系。当一个明星要发布消息的时候，我只要找到对应粉丝的Proxy(代理)。然后我把这个Proxy看成一个计算资源，对它进行一些逻辑处理，会不会更好呢？对，说干就干！于是，freeeyes建立了一个这样的模型。
key value
freeeyes <雄性><2011-05-26><0><FansID...>
winston <雄性><2011-05-26><1000000><FansID...>
Baste7cat <雄性><2011-05-26><1000000><FansID...>
wildfire <雄性><2011-05-26><1000000><FansID...>
modern <雄性><2011-05-26><1000000><FansID...>
对于粉丝，我只需要知道命名的名字，至于之后的东西，我放在一起，按需去取得就行了。这些让程序去做，DB不用管理。好了，这就是key-value模型，也就是NoSQL的一个关键概念（我觉得这里有待商榷，毕竟还是有点关系的，虽然很简单）。想到这里，freeeyes发现，其实对于我而言，有没有DB其实并不重要啊，我只需要有一个管理这个key-value的程序就行了。要的时候我取出来，不要的时候就这么放着吧。
那么，问题还是没有解决，我的数据热区依然是不平均的，那几位爷的粉丝并不重合，我分布到10台服务器上，依旧不能给我解决问题，怎么办？我能不能这么组织数据，我允许数据有一些冗余，毕竟硬盘现在便宜的要命。10台服务器，每个服务器放上50%的全部数据，这样，我获取数据的时候，赶上谁就是谁，找到了就不去别的服务器去找。这样命中点不在唯一，增加了速度。热点也在变的模糊，为了增加效率，我把这些经常访问的key放在内存中。每次你找的时候，都从这些内存中去找。找到一个就返回（别的服务器上可能存在相同的数据，但是只以找到的第一个来获取）。这样的手段，我们姑且叫它"模糊热区算法"(呵呵，我发明的名字，大家理解意思就行了)。更新数据Value的时候，我需要要更新到所有区域的对应的value。不过这个可以慢一些，我只要保证每次读取的时候是最新的就可以了。那么，添加一个key怎么办呢？我记得小时候学过天文，那时候，天文学把宇宙描述成一个球的形象，星座和星星只是其中的几个点而已。那么，如果我把这10台服务器所提供的资源想象成一个球，每个服务器只是球中的一个区域，那么我添加的时候，只需要随机找到球上的一个点或者几个点（考虑到数据冗余备份），扎几个大头针就完成了，每次查找，我只要找距离我最近的那个大头针就行了。对于我这套key-value体系，其实并不需要所有的数据都要有冗余，我可以根据系统运行的时间，你必然要频繁的调用数据，而对于NoSQL，它只需要把经常改写和读取的数据，冗余备份到不同的服务器上，这样，从其中任意一个节点访问到这个数据的可能性就会越来越大，所以好的NoSQL系统，都是依赖运行时去完善数据平衡的，运行时会优化自我（这种AI，不同的NOSQL算法不同，但是原理都是一样的）。冷数据不需要过多冗余存储，经常访问的数据需要大量的冗余存储。就像好车一样，你得多多磨合几千公里，油耗和系统机能才会体现出来。NoSQL当你调用次数越多，热点就越模糊。最后趋于平衡的一种最优曲线。所以，要用好NoSQL，就要有大量的数据请求去"磨合"它。否则，NoSQL的架构意义就不大了。需求决定一切，并不是NoSQL在什么地方都是高效的，弄不好它会比DB效率更低。
好了，freeeyes解决了数据热点的问题。我可以架设一组NoSQL数据集群,来满足我对数据的读取需要，架设好了效果不错，不过，modern又来找freeeyes了，我的粉丝在大量给我留言做交互，他们之间还想互相留言。虽然数据稳定了，但是还是太慢了。
于是freeeyes开始分析，我的数据集群已经是最优的了，那么，还会慢在哪里呢？
入口？请求入口，对，就在这里。我再增加10台服务器（现在后台是10台DB集群，还有这10台业务服务器），当我面对海量的数据订阅和转发的时候（怎么越说越像微博架构？），因为这些请求对于freeeyes来说都是固定的。那么我能不能没台服务器上都提供相同的SendMessage()方法？可以，当然是可以的。
于是，我把一样的逻辑代码和接口，复制10份放在10台逻辑服务器上。它们对数据的依赖，是我的NoSQL集群。
freeeyes太激动了，这样的架构，非常适合大量并发的请求了。
那么，我们现在可以把10台逻辑服务器想象成一个个"网格"，这些网格是为了满足一系列的相同的任务而做的。比如我可以建立一个用户数据维护"网格"矩阵，一个用户发送和接收邮件的"邮件"矩阵，一个用于玩家评论和相互转发的"评论矩阵"。如此等等。。
呵呵，讲到这里，你是不是对"网格"有了一点感觉了？
网格适合于大量的重复性动作运算，逻辑不变，数据不同的大并发处理。
那么，这么看来，我的服务已经可以满足以上几位大爷的需求了，真是这样吗？BOSS开始找freeeyes了，你光为这几个用户，居然消耗了我20台服务器！太贵了！我要求你必须降低成本！
得，freeeyes还不能高兴的太早。服务器是多了点，我真的需要这么多的服务器吗？能不能做到，我按照业务量的需求，一点点的增长服务器数量，如果服务器负载达不到了，我只需要横向扩展服务器，增加"网格"就能满足我的需求呢？当然可以做到，只不过，在这上面，我们需要一个处理负载均衡的节点，这个节点用于将需求分发到注册在上面的所有"网格"节点上，并且根据每个"网格"的负载，动态调整各个网格中的"负载"状态，稀释对"网格"请求的单个热点。
当然可以，现在的主要"网格"计算就是提供这些解决方案的。
那么，聪明的你可能问，你且住，你的这个控制网格压力的节点，会不会有单点故障源？问的太好了，如果你想到了这个问题，说明你距离了解网格已经越来越近了。是的，没错，控制网格压力的节点，可能会出现任何情况，崩溃，不响应等，不过，现在的"网格"产品中，大部分都为我们想到了这一点，所以会有一批备份"节点"时刻准备着。当一个"节点"挂掉或者不响应，网格系统会立刻切换到备用节点。尽量减少单点造成的故障损失。那么，再进一步，我能不能有一种机制，当当前网格能满足我需求的时候，我只用一个网格，如果满足不了，中心控制节点可以帮我启动新的网格呢？如果访问压力下来了，就适当的关闭某些空闲的"网格"？可以，当然可以。我只需要在控制节点上添加一些规则，当某些条件达成的时候，我就会启用新的网格，达不到的时候，就不用这些服务器。
说到这里，freeeyes想起百度架构师的一句话:"我们不怕攻击，你的访问越多，我后面几千台备份的服务器等着被你压呢！"
哈哈，明白了吧，就是这么回事。一切全部取决于这个节点控制网格的机制。其实这个算法也不难，聪明的你肯定可以自己写一个差不多的出来。
看吧，网格并不神秘吧，其实，网格的核心思想，就是"模糊一切可以模糊的单机热点！利用更多的硬件组成一个大服务器。"，就这么简单。
好了，了解了想法，很多网格产品我们就可以抱着这个想法去检验和实践了，网格计算有一部分产品，NoSQL比较适合网格的数据存储，具体还要看看，如果我们有一个"网格"产品，怎么使用。我就拿ICE来举例吧。
首先，有一个ICEGrid的概念，就是我上面所说的中心节点，这个节点用于管理下面的所有"网格"，提供我负载分压的请求。
我先创建一个叫做config.grid的文本文件。
然后添加如下代码
IceGrid.InstanceName=FreeeyesGrid
#
# IceGrid registry configuration.
#
IceGrid.Registry.Client.Endpoints=default -p 12000
IceGrid.Registry.Server.Endpoints=default
IceGrid.Registry.Internal.Endpoints=default
IceGrid.Registry.Data=db/registry
IceGrid.Registry.PermissionsVerifier=FreeeyesGrid/NullPermissionsVerifier
IceGrid.Registry.AdminPermissionsVerifier=FreeeyesGrid/NullPermissionsVerifier
IceGrid.Registry.SSLPermissionsVerifier=FreeeyesGrid/NullSSLPermissionsVerifier
IceGrid.Registry.AdminSSLPermissionsVerifier=FreeeyesGrid/NullSSLPermissionsVerifier
# Trace properties.
#
IceGrid.Node.Trace.Activator=1
#
# Dummy username and password for icegridadmin.
#
IceGridAdmin.Username=freeeyes
IceGridAdmin.Password=123456
IceGrid.InstanceName是你的节点名称，你可以起你喜欢的名字，中文也无所谓。这对应一个ICE工具可以查看，这个工具下面我会说明。
IceGrid.Registry.Client.Endpoints=default -p 12000
IceGrid.Registry.Server.Endpoints=default
IceGrid.Registry.Internal.Endpoints=default
这部分设置是让网格可以顺利的找到你的这个中心节点，并接受节点的管理。
IceGrid.Registry.Data=db/registry
这里你需要在config.grid的当前目录里面建立一个db/registry/的文件夹，用于存放节点的运行和错误日志。里面什么都不用创建。Grid启动后会填充里面的文件，有兴趣可以运行起来看看。当然，你可以改这个目录的名字，只要你喜欢。单层目录也可以。
IceGridAdmin.Username=freeeyes
IceGridAdmin.Password=123456
这里设置的使用工具访问管理这个中心节点的时候，需要通过的用户名和密码，试想一下，如果任何人不通过认证都能链接控制中心节点，岂不很糟糕？
好了，如果你是windows的话，再建立一个bat文件，在linux下同理，建一个sh文件。以windows为例。在bat文件下添加如下内容：
icegridregistry --Ice.Config=config.grid
config.grid这个名字就是你上面我让你建立的onfig.grid文件，只要你喜欢，你可以换成任何你喜欢的文件名和后缀。
好了，控制节点建立了。
下面切换到你的ZeroC的文件目录下，在bin目录下，有一个IceGridGUI.jar的文件，运行它。它是一个Java写的管理工具。
然后点击如下图：
点击上面红框里面的按钮，然后会弹出如下界面：
呵呵，看到了吧，在这里输入你的config.grid里面设置的信息。四个方框里面的信息都要填写啊。
如果成功了，会显示如下画面
看到了吧，你的节点已经建立了，只是，节点下面还没有设置任何"网格“。
再让我们看看，"网格"是怎么和节点关联起来的。
我们再在config.grid里面建立一个xml文件，姑且叫做application.xml
好了，让我们看看这个xml里面在干什么
**********************************************************************
Copyright (c) 2003-2007 ZeroC, Inc. All rights reserved. This copy of
Ice is licensed to you under the terms described in the ICE_LICENSE
file included in this distribution. <node name="localhost">
**********************************************************************
-->
<icegrid>
<application name="TestPalyerNode">
<node name="node-Test">
<server id="TestServer" exe="python" activation="on-demand">
<property name="Ice.ThreadPool.Server.SizeMax" value="1000"/>
<log path="${server}.log" property="LogFile"/>
<description>用户信息服务网格矩阵</description>
<option>Server.py</option>
<adapter name="TestServerAdapter" endpoints="tcp"
register-process="true">
<object identity="TestServer/Center" type="::TestServer::Center"
property="Identity" />
</adapter>
</server>
</node>
</application>
</icegrid>
好了，以上的配置，让我建立了一个node，这个node就是一个"网格"矩阵的一员。这个Node我们姑且叫做"用户信息服务网格矩阵"，服务我上面说的那个sendMessage()例子。这里我们要指定一些参数。
<server id="TestServer" exe="python" activation="on-demand">
这里的id是你的服务器名称，你可以用中文，exe="python"指的是你用的何种语言，也可以exe="C++"。ICE会根据你的这个参数调用不同的语言解析器来运行你的代码。当然，C++不是脚本语言，不需要解析，那么就直接是exe名称好了。我这里用python。（这里说一句我的实话，我觉得支持网格的远程RPC体系，脚本语言是首选，在这样的系统下使用C++除非是特别的性能需求，否则没有多大意义，脚本语言最大的好处是所见即所得，编译方便，查看方便，开发门槛低。）
<adapter name="TestServerAdapter" endpoints="tcp" register-process="true">
这里设置一下你的节点Adaptername，用于别的程序可以通过proxy和你的这个Adapter关联调用。endpoints="tcp" 指的是调用模式，可以是tcp，也可以是UDP，更可以是SSL，看你愿意用什么。
这里有一些ICE的高阶应用，可以定义一组相同条件的node继承于一组相同配置的（<server-template id="PlayerTemplate">参数），这里就不在这里讲述了，有兴趣可以看我以后的文章。
好了，写完这个文件，保存一下。
然后还是用我们刚才的IceGridGUI.jar，在执行完上面的三个步骤以后，
点击看下图：
点击红框的地方。
然后会弹出这个界面：
选择你的application.xml所在路径和位置。
成功后左边的树会变成这样：
好了，你的ICE节点和node的关联已经建好了，简单吧，至今你还一行代码都没写呢。"网格"体系已经建立起来了。方便吧。
你这里看到的node应该是灰色的。那是因为你这个节点还没有启动。现在让我看来看看，怎么写一个"网格"并注册到上面的节点上去。
你在建立一个目录。
我们姑且叫做IceTestNode吧。
在里面创建一个文本文件，node.grid，然后添加如下代码：
#
# The IceGrid locator proxy.
#
Ice.Default.Locator=FreeeyesGrid/Locator:default -h 192.168.1.XXX -p 12000
#
# IceGrid registry configuration.
#
IceGrid.Registry.Client.Endpoints=default -p 12000
IceGrid.Registry.Internal.Endpoints=default
IceGrid.Registry.Data=db/registry
#
# IceGrid node configuration.
#
IceGrid.Node.Name=TestPalyerNode
IceGrid.Node.Endpoints=default
IceGrid.Node.Data=db/node
#IceGrid.Node.Output=db
#IceGrid.Node.RedirectErrToOut=1
#
# Trace properties.
#
IceGrid.Node.Trace.Activator=1
这里Ice.Default.Locato指的是你远程住节点的位置，当这个node启动的时候，会链接你远程的主节点，点亮你的"节点灯"（在IceGridGUI.jar里面可以看到你的节点灯的亮灭状态）
IceGrid.Node.Name=TestPalyerNode这里的TestPalyerNode就是你在application.xml里面对应<application name="TestPalyerNode">的name的名字。
这样，主节点会知道对应的那个node链接上来了，并处于"激活"状态。（已经成功机会，节点灯会亮，变成绿色，否则是灰色，属于未激活状态）
IceGrid.Node.Data=db/node 这里设置你的这个node的执行日志存放地点。和config.grid一样。
其他的参数，如果是初学，你还不用理解，照抄就行了。如果想进一步理解，请查看ICE的相关文档。大都是一些配置相关的东东。
在application.xml的TestPalyerNode节点下，有一个参数。
<option>Server.py</option>
当grid收到请求的时候，会远程调用TestPalyerNode当前目录下的Server.py激活"网格"，并提供相应的服务。
好了，写道这里，一个"网格"的ICE矩阵就建立起来了。至于矩阵中"网格"的使用技巧，有很多，呵呵，洋洋洒洒写了这么多，等有兴趣的时候，我会继续记录下来，今天嘛，就写到这里吧，写累了，呵呵。 不太理解 这篇里提到的nosql 对网格运算的意义？ 只是想说明它的 key-value 适合分布到进程的内存里管理么 这里要说明一下，NoSQL对于网格中的运算，一是分布式的内存存储，二是稀释热点。
什么叫做分布式的内存存储？比如我有一个战斗逻辑模块的服务器，用于玩家之间战斗的计算，如果游戏比较火，你一台战斗逻辑服务器运算不过来了，于是可以横向展开成两台，用户可随机链接其中一台获得战斗中间数据和战斗结果。因为每次战斗过程都是若干个回合组成，所以每次回合请求未必会都到一台服务器上去运算，比如回合1在服务器1上运算，回合2的请求在服务器2上。这时候我的NoSQL必须支持无论我从哪里修改战斗数据，都能及时的获得并修改。这样也为服务横向展开创造了条件，可以根据计算量来动态配置服务器的数量。而与此同时，NoSQL必须也是一个集群服务，后面有若干台NoSQL组成的矩阵。这样，热点才能会得到稀释，不会出现单点频繁访问过热的问题。
另外，上篇文章提到的关于我的多级分布式共享内存和NoSQL到底有什么不同。我这里在说明一下。
在不同的应用下，采用不同的技术，并不是说谁能通吃的。
比如在我上面说的例子中，NoSQL是一个集群服务，适合于网格计算中那些不需要在本地存储缓冲结果的数据业务，因为我不知道下一次用户请求，会在哪个网格上进行，所以我需要任意一个网格都可以通过某节点迅速的获取所需要数据，比如战斗，业务等等。但是对于某些需求，比如用户数据登陆，离开，我可以把用户数据缓冲在本地的网格中，因为这些数据请求往往是固定的，而且并不需要过多的修改和交互。对于这类数据，很适合在本地网格中缓冲数据内容，因为别的网格不会关心这些，即便关心，也是在某些条件下（比如网格故障）。对于这类数据的访问，我没有必要去花费一次IO获得，本地存在就直接获取，已达到最高的运转效能。这一切的应用全是根据需求而定。 这种做法要求 nosql间的数据同步做到及时响应 ,横向同步的开销是否需要得到所有服务器更新确认才算完成,会不会影响及时性？ 不过貌似看过nosql的应用较多的都是面向对数据不敏感的服务，比如说论坛.博客.页面数据这种即使读到脏数据也没关系能满足高并发就行。 你的担心是同步需要的时间和脏数据的问题。
先说脏数据，现在主流的NoSQL对读写都有一套较好的算法，在程序设计上，可以尽量避免同一块数据在同时刻被改写，这是设计应该去做的事情，另外，像MongoDB本身就存在对写入数据的控制机制，保证数据在一次读取中的一致性。
至于你担心的同步时间问题，现在主流的是两种做法，第一个是Master-slave结构，发布订阅机制，一个写或者多个写配合多个读。这种数据关系是存在数据刷入时间问题的。另外一种是球形命中算法，比如memcached，它通过Hash把数据均匀分布在不同的服务器上，取得数据的时候根据Hash映射到指定的节点，从而达到目的。这样的做法数据没有同步时间消耗，可能会多一些IO消耗，不过如果在内部使用，完全可以通过硬件解决。当然，因为冗余问题可能会出现其中一个服务器宕机引起的部分数据丢失的问题，不过这个问题也是可以解决的。
NoSQL最大的挑战就是解决分布式服务器上的数据共享问题，稀释单节点上的热点是需要和设计配合完成的。这建立在你对现在的NoSQL产品理解到多少。 恩想了解的正是同步具体的时间消耗。用作战斗相关的数据修改会很频繁，尤其是战斗单位较多的时候。而且战斗公式里面会去频繁取目标和源的各种属性来运算。不知道理解有误没，freeeyes描述的战斗逻辑模块的服务器是不会在本地存运算数据的(包括之前读过的)，都会到一个非热点的nosql上去取，而nosql之间又是靠同步来保证前一个战斗逻辑模块的服务器运算的结果能在当前的任何一个nosql上能找到 ？
页:
[1]