一、问题的提出

     在九月中开始，我们要打造个性化空间，领导要求的是只进行原型的设计，逻辑的设计，不进行技术开发。其实是严重不正确的，因为个性化空间其特点与现有的技术模型完全不同，现有的技术方案未必能适应开发工作，会造成看起来工作正常，但一旦大规模压力测试将性能一塌糊涂.....

    所以，我们当然要听从领导安排，但私下准备好个性化空间的技术方案也是势在必行。

 

二、初步技术方案

     根据以往的性能优化方案，我们一般采用REDIS进行一级缓存，特殊场景应对大并发，采用二级缓存办法。如果按以前的方式，那么方案是这样的：

    1、在REDIS中记录此空间ID，比如ID:5，有几个模块，都是什么模块ID，比如：模块3，模块9，模块10，模块20，等。

    2、每个模块的内容都单独保存到REDIS中。

    3、每个模块单独记录最后的UPDATE时间，比如如果某个模块的内容删除了，更新了等，都需要在缓存中更新一下此模块的最后UPDATE时间为当前时间戳。

    4、当用户初次来访问时，由LUA查询到此个性化空间有哪些模块， 然后根据每个模块的REDIS缓存，组装成一个JSON串，同时在REDIS中记录一个HASH，

      包含如下信息：哪个空间ID（在KEY里体现），都有哪些模块，这些模块都是最后的更新时间是啥？

    5、JSON数据经NGINX的GZIP压缩后返回。

    6、当用户再次访问时，LUA查询此个性化空间有哪些模块，是不是在模块个数（或个数相同，同容变成其它模块了），模块的最后更新时间有区别，如果没有，则不重复组装，直接拿现成的JSON数据返回即可。

    7、当某个模块的数据变化时，要求JAVA修改模块的最后修改时间，这样，LUA再次查询时，将不再读取保存好的JSON数据，而是重新组装返回，并再次缓存JSON数据。

 

三、技术方案进化

     上面的方案应对一般的需求是很好的，在资源库列表的压力测试中取得了很好的成绩，由1000并发上升到3000并发应该不是问题，但应对这个需求就怕是要有问题了：

     个性化空间具有可扩展性，比如，现在只开发了十个模块，用户最多可以启用十个模块，每个模块的数据量在10K左右，那么最多是100K，数据量不大，后期随着项目的进展，很可能空间出现大规模模块增加，我们以短期内可以接受的50个为上限计算，那么就在500K左右。大家知道，NGINX我们是启用了GZIP压缩的，本来GZIP压缩的效率很高，对于简单的JSON数据我们可以放心的使用GZIP压缩提高传输效率，但对于一个500K的流量，每请求一次就要实时压缩一下，效率可想而知。而此请求是一个动态请求，还不能使用效率更好的STATIC_GZIP方式，那么如果在这样的场景下，CPU的疲劳是可想而知的。因为小的JSON它压缩起来不费力，但大的呢？它也是十分吃力的，这一点我们以前在看JQUERY.MIN.JS每次让它压缩就看的出来，JQUERY.MIN.JS才只有120K左右，它就疲于奔命了，所以，这个方案存在先天的问题。

    为此，黄海提出了一个新的设计思路：JSON数据的压缩不由GZIP实时进行，

参考：

http://www.cnblogs.com/kgdxpr/archive/2014/07/11/3837264.html

每次请求时先检查是不是需要更新gz文件，如果不需要，直接将静态gz文件返回即可。如需要，使用lua组织Redis进行json串的生成，然后调用 系统安装的zip命令进行压缩。

==================================================================================================