Redis在复杂业务ERP产品中的技术应用

Posted 2021-04-07 TQZDB知识屋

作者丨探求者大兵

文字丨2932字，阅读用时3分钟

   上一篇主要是讲了消息中间件MQ在实际项目中的具体应用，解决遇到的一些复杂问题。

   在实际的复杂业务ERP项目中，随着用户访问量和数据量变大，我们的系统架构变得越来复杂，导致系统难以正常运行，为了支撑复杂的系统正常运行，根据具体业务使用缓存数据库Redis是必不可少的。

   在做技术架构设计中，需要根据具体的业务，要解决遇到的非功能需求，才考虑引入缓存数据库Redis。

   下面我从已经上线的ERP系统中，来复盘总结引入Redis的必要性和具体如何应用的，希望对大家有一定的参考和启发意义。

    我主要从以下几个场景来进行阐述说明：

一、Redis缓存会话共享

（1）问题背景

    ERP系统为了支持用户的高并发和高可用访问，使用了硬件负载均衡器F5做应用负载均衡，应用服务器Tomcat集群做具体的业务并发处理。

    对于用户登录ERP系统的会话信息，采用了会话粘滞的方式保持会话。

（2）问题描述

    ERP系统的集群部署，采用的F5负载均衡，虽然使用的会话粘滞这种方式，但是有时候会出现一些负载不均衡的问题。

    如果一个服务器节点压力过大，那么负载到这个节点的用户请求一直会访问这节点，而另一个节点服务器压力不是很大，资源没有得到充分利用。

    如果其中一个节点宕机了或网络不稳定，负载均衡器F5负载这个节点的用户会转移到另一个节点，会提示登录会话超时，用户需要重新登录一遍ERP系统。

   如果是主从模式的缓存同步架构，会进行缓存同步会话，那么即使请求转移到另一个节点，用户还是能正常访问的，没有违和感。

（3）问题分析

    由于负载采用的是会话粘滞方式，一旦一个节点出现压力过大时，这个节点的用户请求就会一直转发到这个节点，对于这部分用户来说系统就容易出现卡顿感。

    如果是服务器直接宕机或网络中断，那么下次该服务器节点的用户请求会转发到另一个服务器节点，这个新节点没有存储该用户的登录会话信息，就会出现登录失效或超时的提示，用户只能重新登录，在新的服务器上创建会话缓存信息。

    如果是主从缓存同步架构模式，虽然请求转移到另一个节点没有什么问题，但是对于网络来说开销会随着节点的扩展而变大。

（4）问题解决

    要根本解决会话粘滞带来的问题，就要采用会话共享的模式，在负载均衡端考虑采用轮询路由策略。

    可以考虑使用缓存数据库Redis或Memcache实现缓存会话共享，从而让各个节点都可以从该缓存里直接获取会话。

    在缓存会话共享模式下，即使有一台服务器节点宕机了，这个节点的用户请求由负载均衡服务器转发到其他的节点，用户无需重新登录系统，影响体验无感。

     即使在主从缓存同步架构模式下，也不会存在各个节点会话不一致的情况出现，同时节点扩展越多，网络之间的缓存同步开销也就不复存在了。

二、Redis缓存热点数据

（1）问题背景

    应用服务集群架构开始采用的是主从架构模式，ERP系统的元数据，配置参数，公用数据等，都是通过主节点的缓存同步功能实现各个从节点的缓存刷新，从而使各个节点缓存数据保持一致。

（2）问题描述

    主从模式的缓存同步架构，主从节点之间会缓存同步通信，有时候网络会不稳定，ERP系统会出现个别节点缓存数据跟其他节点数据不一致的情况。

    比如，缓存的单据模板信息不一样，有的节点缓存的这个单据有职员字段，另一个节点没有职员这个字段，导致用户有时候看不到这个单据上某个字段数据。

（3）问题分析

    由于节点之间的缓存同步依赖于网络的稳定性，所以网络有时候跌宕不稳定会导致个别节点缓存数据同步不一致，有的节点同步了最新数据，有的节点依然没有同步数据。

    比如，上面问题描述的单据模板显示字段不一样，另外如果是缓存同步会话，那么可能会出现用户访问系统时提示用户重新登录系统或会话超时的问题。

（4）问题解决

    在主从模式的缓存同步架构下，如果采用Redis或Memcache缓存公用数据或热点数据，各个节点不再进行缓存数据同步，这样就不会存在数据不一致的情况出现。

    此时的主节点服务器相当于一个授权中心，只要从节点每次一启动，就要向主节点申请启动ERP系统服务的授权。

三、Redis分布式缓存锁

（1）问题背景

    ERP系统架构如果开始采用单体架构模式，那么只用本地缓存锁来控制业务并发操作就可以了。

    比如，多组织模式下的结账或反结账，电子会计档案归档，共享系统的派单等操作都可以使用本地缓存锁控制业务并发重复操作。

（2）问题描述

    在单体架构模式下，本地缓存锁是可以控制住某个组织某个账簿同时重复结账或反结账操作以及其他关联业务操作的。 

    如果ERP系统放在集群架构下，那么多用户可以同时对同一个组织和账簿进行结账或反结账并发操作，以及可以并发操作关联业务。

    比如，用户A进行A01组织下的A001账簿进行结账业务操作，可能需要花费稍微长的时间，此时用户B也可以进行A01组织下的A001账簿结账业务或者用户B可以进行反记账业务操作。

（3）问题分析

    由于ERP系统是集群部署的架构模式，本地缓存锁是控制不住在多个节点下并发操作同一项业务，因为各个节点都有本地缓存锁，只对本服务器并发操作有控制作用。

（4）问题解决

    ERP系统采用Redis或Memcache作为分布式架构下的缓存锁，可以控制住在各个服务器节点下多用户对同一业务的并发操作，从而实现业务并发防重操作。

    比如，结账或反结账，电子会计档案的防重归档操作和共享系统的防重派单操作。

ERP系统结账加锁防并发操作如图所示：

共享系统的并发防重派单操作如图所示：

电子档案归档防重操作跟上面的采用Redis分布式缓存锁处理都差不多，就不在列举了。

四、Redis异步缓存进度

（1）问题背景

    在ERP系统中，用户有时候会做些批量业务操作或计算业务操作，比如单据批量导入或导出，业务报表的计算，财务和业务子系统的月底结账等。

  

（2）问题描述

    用户进行单据大批量导入或者结账操作时，都要花费很多时间，由于界面没有进度提示，不清楚业务进行到什么情况，交互性比较差。

   特别是有时候单据或基础数据大批量导入时，页面直接就会卡死，有时候令用户很崩溃。

（3）问题分析

    由于单据批量导入或结账操作都是长事务操作，所以服务器响应时间过长，对于用户来说只能等待。

    由于在用户界面上没有业务执行进度提示，所以用户了解不到业务执行情况，用户体验感就比较差。

    用户经常用的导入页面卡死，主要是采用了同步提交和同步后台处理操作，浏览器端只能长时间等待响应，显示给用户的现象就是页面卡死不动。

（4）问题解决

    ERP系统采用Redis或Memcache可以实现对各个长事务业务操作整个过程的进度记录保存，及时向用户展示业务执行的进度情况。

进度显示如下图所示：

说明：单据在批量导入的时候，采用的是同步提交方式， 在服务器的后台程序里单独开了一个后台线程用于单据导入的处理，实现异步导入处理，然后同步提交的请求处理后立即响应给用户，这样用户就不会觉得页面卡死。

    同时，在用户当前页面定时的提交进度刷新请求，通过应用服务器后台从Redis缓存数据库里去获取当前单据数据导入的执行进度。

    这样用户就可以看到当前业务执行进度情况，用户体验性比原来好了很多，更具有交互感，减少了用户等待的忧虑。

如下图：

    结账的操作也是类似，如果用户把当前操作的页面关掉后，再也看不到当前页面业务执行进度情况，但是用户可以从公用业务执行进度列表上查看到各个长事务业务执行进度。

    总之，redis可以在负载均衡时用来做缓存会话共享方便优雅扩容应用，分布式缓存锁实现并发防重操作，可以做公用数据和热点数据缓存提高系统性能，也可以做业务执行进度的中转站提高用户体验性。