背景
由于用户数的飙升，推荐使用的技术栈也在不断升级，以满足更高并发和更大数据量的推荐场景。
推荐相关的原始数据从小几十万到几百万，到几千万，再到上亿。
推荐1.0
从全库的用户数据中load出满足条件的用户，在jvm做计算，得到推荐结果。
随着用户数量的上升，满足条件的用户越来越多，导致计算量越来越大，性能逐渐变低
推荐2.0
一边从数据库中load出满足条件的用户，一边用sql在数据库做计算，直接得到推荐结果。利用索引，性能提升五倍左右。随着用户量继续上升，性能也在逐渐变低。
推荐3.0
将数据库推荐相关的数据，通过canal同步到ES，在ES中对数据重新建模，类似宽表，依靠ES的自定义评分机制，得到推荐结果，性能提升15-20倍。
ES虽然支持大数据量的检索，但是并不适合做高并发的推荐需求。随着并发上来，性能再一次出现瓶颈。
推荐4.0
在正式推荐之前增加一个预推荐的过程，尽可能多的过滤用户，留下不超过一万的数据，然后在JVM内存中做计算，得到推荐结果。
推荐5.0
如果推荐4.0再次遇到推荐瓶颈，可以考虑通过数据建模+机器学习的方式。除此之外，将推荐相关数据自定义压缩后放到Redis中，为推荐提供数据源。
结论
- 如果推荐原始数据只有大几十万，可以直接在java内存中完成推荐。
- 如果推荐原始数据有几千万，一定要做一次预匹配的过程，留下不超过一万的数据，在Java中得到推荐结果即可。
- 如果原始推荐数据大几千万甚至上亿，需要考虑数据建模，将数据源从mysql备份到redis。
- ES适合做大数据量的检索，但是不适合当作缓存来抵抗高并发请求，也不适合用ES脚本做复杂的计算操作。
