服务端优化方案的手段是对服务进行重新规划。对于数据量太大以至于无法在一台机器上存储全量数据的场景，建议采用Bigtable或类似的解决方案提供数据服务。典型的Bigtable的实现包括Hbase、Google Cloud Bigtable等。实际上数据局部性是Bigtable的一个重要设计原则，其原理是通过Row key和Column key两个主键来对数据进行索引，并确保同一个Row key索引的所有数据都在一台服务器上面。通过这种数据组织方式，一次网络请求可以获取同一个Row key对应的多个Column key索引的数据。缺乏规划也是造成服务数量剧增的一个重要原因。很多通过统计和挖掘出来的特征数据往往是在漫长的时间里由不同team独立产生的。而对于每种类型数据，在其产生之初，由于不确定其实际效果以及生命周期，基于快速接入原则，服务提供者往往会用手头最容易实施的方案，例如采用Redis Cache（不加选择地使用缓存会导致缓存滥用）。数据服务之间缺乏联动以及缺乏标准接入规划流程就会导致数据服务数量膨胀。数据局部性原则对规划的要求，具体而言是指：1. 数据由尽可能少的服务器来提供，2. 经常被一起使用的数据尽可能放在同一台服务器上。

客户端优化有如下几个手段：

1. 本地缓存，对于一致性要求不高且缓存命中率较高的数据服务，本地缓存可以减少服务端调用次数；
2. 批处理，对于单机或者由等价的机器集群提供的数据服务，尽可能采用批处理方式，将多个请求合成在一个请求中；
3. 客户端Hash，对于需要通过Hash将请求分配到不同数据服务机器的服务，尽量在客户端进行Hash，对于落入同一等价集群的请求采用批处理方式进行调用。

案例分析

我们的挑战来自于美团的推荐、个性化列表和个性化搜索服务。这些个性化系统需要获取各种用户、商家和团购信息。信息类型包括基本属性和统计属性。最初，不同属性数据由不同的服务提供，有些是RPC服务，有些是Redis服务，有些是HBase或者数据库，参见下图：

通常而言，客户端每个用户请求都会触发多个算法。一方面，每个算法都会召回几十甚至几百个团购或者商家ID，团购和商家基础属性被均匀地分配到几十台Redis里面（如下图），产生了大量的Redis请求，极端情况下，一次客户端请求所触发的团购基础数据请求就超过了上千次；另一方面，用户特征属性信息有十几种，每种属性也由单独的服务提供，服务端网络调用次数暴增。在一段时间里，很多系统都进入了多次请求杠杆反模式，Redis服务器的网卡经常被打死，多次进行扩容，提高线程池线程数量，丝毫没有改善。

在对系统进行分析之后，按照数据局部性模式的原则，我们采用了如下手段，彻底解决了系统多次请求杠杆反模式的问题：

1. 采用大内存服务器存储所有的团购和商家基础信息，每个算法只要一次网络请求就可以获取所有的信息；
2. 服务端采用多线程方式提供服务，避免了Redis单一线程模式下单个请求慢所带来的连锁效应；
3. 借鉴类似Bigtable的数据组织方式，将用户的多种特征采用两个维度（用户维度和特征类型）进行索引，确保同一用户的信息只存放在一台机器上面，减少网络调用数量。

缺点和优点

数据局部性模式并不适用于系统初级阶段。在初级阶段，最小可用原则往往是主要设计原则之一，出于两方面的考虑：一方面，在初级阶段，很难预测所要提供服务的数据是否有效而且能够长期使用，以及未来的调用量；另一方面，在初级阶段，工程师可能无法预测最终的调用模式，而不同的调用模式会导致数据局部性方案的设计不同。对于已经大量使用的数据服务，采用数据局部性模式进行重构必然要改变老的调用模式，这一方面会引入新的Bug，另一方面也意味着巨大的工作量。需要特别强调的是，数据处于系统的最底层，对于结构复杂而又重要的数据，重构所带来可靠性、一致性和工作量都是需要权衡的因素。对于请求量比较小的数据服务，即使一次请求会触发严重的请求杠杆效应，但是如果原始触发请求数量在可预见的时间内没有明显变多的迹象，进行数据服务重构可能得不偿失。

数据局部性模式能够解决多次请求杠杆反模式所导致的问题，但它并非大数据的产物，CPU、编译器的设计理念里早就融入了该模式，所以很容易被工程师理解。虽然过度设计在系统初级阶段是一个要尽量避免的事情，但是理解和掌握数据局部性模式对于设计出一个可扩展、可重用的系统有很大帮助。很多成熟的系统因为多次请求杠杆反模式而导致系统频繁崩溃，理解数据局部性模式的原则有助于提高工程师分析解决问题的能力，而在确认了系统存在请求杠杆问题后，数据局部性原则是一件非常锐利的武器。

避免蚊子大炮模式（Avoiding Over-generalized Solution Pattern）

原理和动机

“用大炮打蚊子”本来是大材小用的意思，但是细致想一想，用大炮打蚊子，成功率不高。对于开发工程师而言，一方面为了快速承接业务，按照方案复用原则，总是尽可能地利用现有系统，这使得系统功能越来越强大；另一方面，提高系统的通用性或可重用性也是工程师们在设计系统的一个重要目标。随着这两个过程的相互独立演化，采用通用方案解决特定问题的现象随处可见，形象地说，这就像大炮打蚊子。大炮成本很高，蚊子的数量众多，最终的结局往往是蚊子战胜了大炮。

“避免蚊子大炮模式”是经济原则在运行时系统的运用，它要求采用最节省资源（CPU、内存等）的方法来解决所面临的问题，资源浪费会带来未来潜在的风险。工程师接到一个需求的时候，需要思考的不仅仅是如何复用现有的系统，减少开发时间，还需要考虑现有系统为处理每个新需求访问所需运行时成本，以及新需求的预期访问量。否则，不加辨别地利用现有系统，不仅仅增大了重构风险，还有可能交叉影响，对现有系统所支持的服务造成影响。从另外一个角度讲，工程师在构建一个可重用系统的时候，要明确其所不能解决和不建议解决的问题，而对于不建议解决的问题，在文档中标明潜在的风险。

案例分析

我们的挑战是为移动用户寻找其所在位置附近的商家信息。美团有非常完善的搜索系统，也有资深的搜索工程师，所以一个系统需要查找附近的商家的时候，往往第一方案就是调用搜索服务。但是在美团，太多的服务有基于LBS的查询需求，导致搜索请求量直线上升，这本来不属于搜索的主营业务，在一段时间里面反倒成了搜索的最多请求来源。而搜索引擎在如何从几十万商家里面找最近的几百商家方面的性能非常差，因此一段时间里，搜索服务频繁报警。不仅仅搜索服务可用性受到了影响，所有依赖于LBS的服务的可用性都大大降低。

在对系统分析之后，我们认为更适合解决最短直线距离的算法应该是k-d tree，在快速实现了基于k-d tree的LBS Search解决方案之后，我们用4台服务器轻松解决了30多台搜索服务器无法解决的问题，平均响应时间从高峰时的100ms降低到300ns，性能取得了几百倍的提高。

缺点和优点