一个简单的Redis结合Spring MVC架构以及实现过程

为了加快开发人员对公司项目的理解、更加容易入手和对公司项目的整体把控。

整体框架

首先介绍公司项目的整体框架，闲话少说，直接上图

 

整体性能分析

这就是公司的一个整体的架构，为了开发人员对架构的侧重点的把控，接下来先分析一下架构的整体性能并畅谈一下架构的功能扩展分面。

前台项目

还是从前台项目说起吧。毕竟做这么多工作，最终的目的是把公司的产品展示给客户看，给客户更高的用户体验

用了提高前面页面的读取速度，所以设计者采用具有“内存数据库”美誉的Redis数据库，但是Redis的缺点就在于事务的处理和检索。所用设计

者又采用了第三方全文检索来进行弥补。而且这个第三方全文检索的检索速度绝对不是MySQL的检索速度所能比的，至少检索速度在MySQL

检索的数千倍甚至上万倍。

页面缓存

用户访问首先会经过一个页面缓存OSCache如果缓存中已有该页面内容，则直接返回内容给用户，这样极大的减少了服务器的压力。建议接手者

尽量在该块的扩展，这样能极大的减少服务器的压力，并提供非常之高的用户体验。

全文检索&Redis

如果用户的访问访问的内容在OSCache中不存在，也就是访问穿透了页面的缓存，这里首先会走全文检索去检索服务条件的内容再从Redis中取出

相应的内容，通过freemarker静态渲染之后返回给用户。

发布项目

该项目具有极大的扩展性，现在主要是做数据资源的同步，后期可以考虑做静态页面的发布，主要处理运算和IO这一块的功能，最后如果访问量

暴增，可以在这里做MySQL的主从库的同步，真正的实现读写分离。

技术实现分析

该项目主要采用了线程池的技术，主线程不断去扫描gt_template这个数据的表，因为公司员工对后台数据的更新的数据都会被mysql中的触发器给触发到gt_template这个表中，gt_template的数据库的字段如下：

其中的source_id是资源的id，如线路的id或酒店的id，source_type为资源的类型，

主线程一旦扫描到数据就会根据这个资源的类型从线程池中开辟新的线程并选择对应的发布程序进行发布。

发布程序会根据source_id也就是资源的id去MySQL数据库中提取相应的产品，如果产品不存在，则说明该数据被删除不存在了，为了减少脏数据

的存在，所以发布程序也做一次清理的过程，不管该条产品是否在全文检索Solr和非关系性数据库Redis中存在，都做一次清理该产品；如果产品

存在，则应该根据产品的当前状态做及时的处理，如果是发布状态则做如下的操作：1、清理脏数据，直接从全文检索Solr和非关系性数据库Redis

中把该条产品清理掉；2、把最新的数据更新到全文检索Solr和非关系性数据库Redis中。3、从gt_template中删除该条记录。

后台项目

该项目相对比较简单，主要就是采用Spring MVC模式加上mybatis实现的，相信开发人员对此种架构已经是相当的熟悉了，我就不在这里卖弄了，

免得被扔鞋子、臭鸡蛋等。

 

关于架构的性能就写这么多了，免得大牛们看得不下去了。由于自己知识浅薄，就写到这吧，大牛们轻拍。