让项目在大脑中升级

经常有人跟我说他做的项目没有亮点，要不要去学习一个别人的项目然后出去面试。我都建议他们不要这样做。更好的做法是多学一些知识，再回头看看这些知识能解决哪些问题。如果感觉能解决一些问题了，就可以在头脑中将原有的项目升级到2.0版本，3.0版本。这样，你出去说的时候，虽然没有实际动手做，那也是你自己的项目，确确实实体现了自身的能力。

具体怎样做呢？今天我带大家用头脑升级一个我十几年前做的项目。

那是乐视网最火的那几年。因为我之前一直做创新项目，后来创新项目移交给了别的部门，领导比较看重我，没有把我打包给出去。我就转回了个新项目组，才发现核心项目有些问题没有解决。

主要问题有三个。

第一个是日常至少有1%的请求会超时。

第二个是在热剧热播情况下超时更加严重。

第三个是向其他对接方比如搜索引擎团队同步数据问题。

因为我去到核心团队不久，整个公司就出现了一些情况，我就去美团了，所以当时这三个问题当时都没有解决。我只是说一下如果公司发展顺利情况下我会怎么解决问题。

日常至少有1%的请求会超时

先说一下背景:我们当时是负责全公司的媒体资讯服务。主要是视频数据和专辑数据。视频数据主要是视频名称，视频链接，视频介绍等。而专辑是所有围绕着一个主题的视频数据。比如<甄嬛传>这个专辑里就包含了76集视频的信息，相关花絮，还有对应演员的相关视频，共一千多个视频信息。就是说视频信息很小，是可控的。但是专辑数据有可能很大。

当时没有做任何分页，而是把所有视频和专辑除了在数据库做持久化存储之外还在redis里缓存了一份。其实像这种大专辑是不适合放在redis里的，会产生大Key问题。所以这种存储方式不但让我们自身产生获取数据超时的问题，而且因为redis集群是公用的，还对其他团队的请求稳定性也造成了影响。

更好的方式是存储和查询时，对于专辑数据采用分治的方法。存储在redis时，专辑数据只存储id列表。一千多个ID，假设ID是long类型的，就是说占用32bit，也就是4B。一千多个ID是Redis可以接受的范围。

1. ‌对Redis来说如果String类型的value值大于10KB，通常被认为是大Key。‌其他类型‌：如Hash、Set、Zset、List等，当它们的元素个数超过5000个时，也被视为大Key‌。
2. 存储问题解决之后咱们来看查询问题。查询时一个专辑数据太大会造成网络带宽占用过大，传输时间过长等问题，更好的方式是让调用方分页获取。如果调用方有获取全量的需求，那就先请求专辑里包含的视频ID列表，再一个个获取视频信息。

在热剧热播时超时更加严重

这是一个典型的热点问题。主要特点是热剧刚开播时短时间流量巨大。工作时间长一点的大概还记得那个年代，哪个明星结婚，微博都是挂的。都是短时间流量大，那时候应对策略不成熟导致的。

应对这种问题常规见效手段有两个。一个降级非核心服务，一个是提前扩容。这里我为什么用的是提前而不是弹性扩容。因为临时扩容到实际完成扩容是需要时间的，一般是分钟级别，可能来不及。

除此之外，对于热点数据，可以加一层本地缓存。将数据缓存在服务器内存。请求数据不用去Redis取，进一步减少开销提速。

向其他对接方比如搜索引擎团队同步数据问题

因为这是十几年前的项目，那时候我们同步数据使用的还是共享磁盘加直接调用的方式。当时所有的变更增量都是直接RPC调用搜索引擎那边提供的数据接收接口。因为调用时难免会出现超时，网络抖动，服务重启中等问题。所以隔一段时间两方的数据就会出现少量的数据不同步。因此，我们每天还会同步一次全量，全量数据会压缩存放到共享磁盘空间给搜索团队使用。

当时遇到的问题是全量压缩时，速度太慢，要好几个小时，这期间有可能产生新数据，接收方要做非常严格的逻辑处理。我曾经试图减少压缩耗时到半个小时，结果32核64G的物理机直接让我把CPU打到100%，只好重启恢复。

现在消息对接技术已经很成熟了。现在来设计，只要更新时间严格是有变更的时间戳。不管是一天重发一次的全量数据还是实时发送的增量更新数据，直接扔到消息队列中，只要保证消息不丢失即可。接收方做的也只是如果更新时间大于自己这边存储数据时间的就更新，否则就不更新即可。

以上是2.0的版本。是从解决问题出发的。问题解决了，业务持续发展就会遇到新的问题。比如除了乐视自有的视频数据，还会对接一些第三方。第三方数据怎样来存储的问题。因为三方数据结构受外部影响大，变更较频繁，所以如果条件允许，我可能选用mangoDB来存储。通常来讲一个业务发展较好的项目会面临着三高问题，业务复杂性和稳定性方面的多重压力。当然，对技术的考验也更全面。