最近在做分布式的服务，主要就是提供字典给客户端查询，或者有客户端写入，主要用于增量式的服务参考历史信息，完成批量处理需要完成的任务。看着还是很吸引人的，但是要想这个服务做得好，还是有许多需要注意的地方，首先，我们想象中服务的模型就是，多台服务器每台负责一部分数据，客户端对这些数据的访问是随机的，客户端来的数据与服务端存储的数据分布是一样的，这样不会产生热点问题，不会产生数据倾斜，随机性就可以很好的保证分片之后每个节点存储的数据量是差不多的，这是负载的均衡，每天新增加的数据的特点（随机性）也决定了不会出现热点服务，如果每天的采集量在整体上有倾斜的，那么还要找出这个倾斜的规律，或者，根据这部分增量数据的倾斜情况，调整服务器上的数据分布，这就要用到数据迁移。关于服务器节点间的数据迁移，最大的瓶颈就是网络带宽了。因此也没什么很好的方法可以减少数据消耗，唯一的办法就是，设计一个好的数据分片策略，尽量减少数据的迁移。那么怎么才算是好的数据分片策略呢，似乎跟实际的应用场景关系很密切，但是一个通用的需求就是：负载尽量均衡，每天增加的数据分片也要用服务器的分片策略，也要均衡，均衡度一样，增量的数据为服务器的子集，当增加的数据《《服务器的历史数据的时候，只要保证增量处理的请求不超过每台机器的承受能力，而且处理时间每天也满足需求，就可以了。
现在还是转入我今天想说的正题吧：分布式服务性能评测指标：1.随机读的响应能力，这是受客户端的并发量影响的，2随机写的性能，这时候服务端会加锁，这是比较影响性能的。数据库如果处理好这一点，将是一个性能很棒的数据库。
我们测试的时候，会不知道如何下手，从什么角度对这个系统进行评测，其实此时我们可以考虑实际应用中，我们最疑惑的问题，我们要处理一部分数据，然后想多线程处理，最大程度的使用服务器端的资源，但是并发量太高，反而给服务器造成很大的负担，导致阻塞，最担心的情况是会出现崩溃，如果不崩溃，那就是服务阻塞，某些服务花很长的时间完成，拖慢了整个处理的进度，因此合理控制客户端的并发数目还是很重要的，如果用mapreduce进行处理，每个maptask建立连接，这样连接数目不会大，但是因为是不同的客户端发起的连接，其并发性还是比较高的（猜测）。如果是在map阶段跟服务器连接，那么我们一般每个task维护长连接，每一条记录，发起一个请求，或者多个。这样只需要服务器支持5000top的并发度，当然这只是跑一个hadoop作业，如果多个作业流水线的并行运行，每个发起3000个请求，那么还是可能会上万的。此时影响服务性能的主要因素就是L服务器端的处理能力，服务器读写数据的速度，数据如果存在内存中，似乎还好说，如果数据量很大，就需要用个数据库，这时候对数据库的读写性能要求就比较高了。
我们还需要研究，多大的并发量处理固定的一批数据花时间怎么变化的，怎么优化可以使得时间和并发性控制在一个均衡的水平呢？
这里除了网络带宽的影响，就是服务器端存储能力了，需要速度，缓存是必不可少的，当然涉及到多服务器，数据分片也是要讲究技巧的。数据副本，其实这些需求，也没什么特别之处，主要还是数据库本身性能的优化？
（未完待续……）