奶奶从路边捡来一只小鸡。它总是喳喳的叫，但是周末我坐在那里的时候，它就会蹲在我脚上，很安详的样子。然后小鲜肉就过来说：麻麻，我好想吓唬它。小鸡被吓的到处乱串。我说了挺多话没法让小鲜肉停下来。我就叹了口气在那里看着。一个5岁的孩子本来就不具备换位思考的能力。还有一个问题，我其实根本不知道小鸡是怎样想的。只是觉得它趴在我脚上的时候很安心很安静。晚上下班我会把手伸到笼子里陪它待一会儿，因为我想它是很想自己的妈妈的。

　　本文首发于静儿1986的博客，原文地址是。

　　先说说我们部门的业务。我们部门掌管乐视网所有的视频音频等最核心数据的信息。所有子业务都围绕着这个核心数据。最笼统的分可以分为两块：读和写。

　　读数据除了直接依赖DB的内部操作之外，就是直接通过http请求的RPC调用。因为调用这个接口的业务方非常多，他们用的语言和技术非常杂，http有更好的通用性和便于运营人员等不懂技术的人排查问题，只能内网访问，也很安全。这是部门并发量最大的服务。单台机器QPS一般在2k多，低谷时在1k多，高峰时在3k多。线上11台接口服务器同时工作。但是读数据为了提高并发量，将全量的视频和专辑数据存在了memcached缓存里。所以一旦其他业务方更新了数据会直接发送MQ消息给读数据服务，读数据服务更新了缓存后要给业务方回复消息。

　　读数据还有一种被叫做离线数据推送。这是由于像搜索部门这样的，需要所有视频相关的全量数据，不合适通过接口访问。之前用的是他们直接依赖我们的数据库镜像。但是这样我们这边要进行数据库改造，分库分表或者其他的表结构修改，就要通知各个依赖业务方。所以我们就改用定时全量数据推送给他们和MQ实时数据发消息的方式进行解耦。

　　还有一个面向所有部门同事的服务，就是统一异常平台。部门的所有子业务的异常都会异步发送到统一的Redis中。可以在一个公共的平台统一查看。对于特定业务的，会给特定的同事发出告警邮件。

　　写数据的业务方非常多，我们部门也有。其他部门也有。写数据就是创建，修改和删除。写数据QPS很低。

　　创建时不仅要走我们这边，还要调用云存储，云转码等其他部门的接口。具体流程可参考之前的一篇文章：《一个请求过来都经过了什么》。

　　修改是走我们部门内部系统或者调用我们的API。

　　删除只能走我们部门内部系统，删除接口目前不向其他业务部门开放。

　　我自己目前主要做的就是读数据的部分。离线数据算是我开发的，其他人是拷贝的我的。目前正在进行RPC接口的改造。写我也做过。PGC项目是专业用户进行视频上传的，当年是我做的。这是一个平台。我做过数据接入。就是我们购买一些版权的公司将他们的视频的介质和媒体信息直接ftp放到我们服务器上，或者给我们一种调用方式我们自己去取，这种属于后台服务。我也维护过我们的视频后台系统。是我去美国做数据接入的时候，美国运营同事总是过来找我说我们系统的问题，由于时差，我只能自己动手改了。

　　后台服务可以自己想怎么写怎么写。其他的，不管是读接口，PGC还是后台系统都是采用的SOA架构将业务垂直分解为前端(对于平台来说就是和界面打交道的，对于读接口来说就是业务方调用的)，使用Dubbo来调用数据服务。基于这种设计，一个子业务的代码基本模块都分为API模块，WEB模块(读接口无此模块)，common模块(一些公用工具或者公用POJO), client模块（dubbo服务的接口），service服务(dubbo服务的实现，即服务提供者)。

　　简单介绍一下Dubbo：Dubbo是一种透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。实现了软负载均衡及容错机制，服务自动注册与发现，能够平滑添加或删除服务提供者。

　　下面是今天的重点，吐槽一下我们目前读接口的架构不合理（当然不合理是很正常的，这是一个为期三年的古董），我们新方案已经设计好了。

　　读接口业务简单，并发支持需求大。如果说采用Dubbo层是为了与业务分离，提高服务的复用率，提高数据的统一性。目前一个子业务就自己弄一套Dubbo。有API和WEB两个对前端业务的也将就起到作用了。读接口就是一个api调服务，有啥复用的啊。Dubbo的读接口采用默认的阻塞模式，高并发的情况下Dubbo就会成为性能瓶颈。

　　业务方可以进行数据的更新，他们更新DB后还要维护我们的缓存。我们的缓存采用的乐视统一的CouchBase集群。CouchBase是Memcached的升级版。既然是走Memcached协议，那么就可以使用Moxi代理来提高性能。

　　简单介绍一下Moxi：它基于memcached开发，对于并发的gets请求，做合并来减少和memcahed server的交互。对热点访问的cache会在本地缓存，减少network hops。network hops就是网络路由跳数，距离目的网络所经过的路由器数目。对于某种类型的key，可以异步set。可配置超时时间，也有错误重试机制。

　　各个业务线反馈说Memcached不好用，有性能问题。好多业务线自己换成了Redis，解决了好多神奇问题。撇开这些数据不谈，给你一个用Redis而不用Memcached理由：Memcached的各种强化和代理Memcached自己都可以做，但是没有做。Redis却在不断的更新和优化。

　　还有一个专门维护这个缓存数据一致性的服务。我个人觉得我们系统过分的强调了一致性，却牺牲了性能。下面是一些基本的理论：

　　分布式领域CAP理论：

　　定理：任何分布式系统只可同时满足两点，没法三者兼容。

　　忠告：架构师不要将精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。

　　一致性模型：

　　BASE理论（CAP理论的延伸）：

　　核心思想：即使无法做到强一致性，但是应用可以采用合适的方式达到最终一致性。

　　像我们常用的分布式存储：mysql的主从读写分离，redis缓存的master-slave形式的主从复制都是基于操作记录的，都会有时延，也就是保证最终一致性而已。

　　题外话：基本的理论和名词概念是很实用的。比如在之前公司做搜索引擎的时候，搜索引擎需要分词，分词的分词组件叫Tokenizer。这个不是搜索引擎特有的概念。Java的rt.jar这个最基础类库里有StringTokenizer和StreamTokenizer。如果你了解了这个，就很容易理解理解搜索引擎的分词是干什么用的。

　　再说我们项目中过分强调数据一致性而损失性能和高可用的事情。完全可以不对一致性不那么精益求精。这并不是说不追求完美。追求完美可以提现在哪些方面呢？