软考架构成功上岸了，分享一些练习过的应试八股文，都是速成的，批改合格的。水平有限，勿喷啊。哈哈

摘要:
2021年3月，我参加了某省人大履职系统的开发工作，该系统是一个处理代表履职工作、代表工作站、立法业务、会议管理、建议议案管理等业务工作的综合信息系统。本人在该项目中担任系统架构师职位，主要负责系统架构工作。本文以该项目为例，主要论述了redis数据库在该项目中具体应用。在redis的缓存应用方面，系统使用了redis的Hash数据格式，K-V数据格式,将数据缓存到rddis数据库中，提升了查询性能，在redis的分布式锁的应用方面，系统使用setnx+expire功能，解决了应用集群内的定时任务并发问题和业务并发问题,在发布订阅功能应用方面，我们将消息推送到reids队列中，消费者异步处理消息，提升了系弘吞味量，通过使用redis的各项功能，保障了系统顺利上线。并得到用户的一致好评。

正文:
根据《“十四五”国家推动政务信息化》的文件精神，某省人大决心推动人大履职系统的建设工作。以期提高政务服务水平。我司通过竞标，获得了该项目的开发权。
本系统于2021年3月启动，开发周期9个月，系统主要用来辅助人大机关工作人员处理人大机关内的各项业务。这些业务包含代表履职工作、代表工作站、立法业务、会议管理、建议议案管理等。代表履职工作主要用来管理代表基础信息和代表履职管理，主要功能有代表基本信息管理、代表选任联管理、代表联络站管理、代表“双联”工作管理、代表履职档案管理等功能。代表工作站主要用来管理人大人基层工作站，是连接代表与基层群众的桥梁。主要功能包含基层站点信息管理、驻站代表管理、群众留言管理、远程视频协商、站点信息发布等。立法业务是人大的核心业务，包含立法规划、立法计划、立法起草、立法审议、立法评估、立法清理、法规库建设等会议管理主要包含会议室管理、会议事务管理、投票表决、远程协商、会议室排座功能等。建议议案管理建议提交、建议审核、建议交办办理单位、建议回复、满意度测评、建议统计分析等。本人在该项目在担任系统架构师。主要负责系统架构工作。
数据库主要为了解决大规模数据库集合和多类型数据格式所带来的性能、存储、应用等方面的挑战。常见的NoSQL数据库类型包含键值数据库、列存储数据库、文档型数据库和图数据库。键值数据库以redis数据库、memcached数据库为代表，另外还有EHCache、Guava等本地缓存键值数据库。大多数键值数据库的做法是将数据预加到缓存中，当需要查询数据时，直接从内存中区取，以避免大量访问请求数据库所带来的性能问题。在键值数据库中，redis数据库的功能最为丰富，除了缓存数据，还支持丰富的数据类型、数据持久化、分布式锁、自增键、发布订阅功能等。列存储数据库以HBase为代表，一般作用于大数据架构中，比如在Lambda架构中，使用HBase来存储Sparking计算后的数据。文档型数据库较有代表性的是MongoDB,MongoDB主要用来存储非结构化数据，比较经典的应用是热点评论功能。不仅能存储海量的非结构化的评论数据，且查询性能也十分迅速。Graph数据库主要用来处理各类图型数据。比如电力系统、金融交易分析等。
在本系统中，我们主要采用了redis数据库，在改善系统性能、处理某些特殊功能点方面都有使用。这些应用点包含缓存应用、分布式锁应用、发布订阅功能等。
缓存应用方面
性能是系统的一项非常重要的指标，对用户使用系统的舒服感方面有重要的影响。在本系统使用前期，由于用户量较小，使用频次低、业务数据量小，因此，通过简单的sql优化、代码优化或少量的许应用内存缓存等方法,即可满足用户的使用需求，后期，随着系统的推广，用户量已达10万级别的规模。产生的业务数据也成倍的增长。为了满足查询性能要求。我们对系统添加缓存机制。以改善系统性能。在缓存机制的设计方面。我们先是对业务数据进行了梳理。划分了需要缓存数据的类型。这些类型有固定型数据、热点查询数据。固定型数据指那些基本不会产生变化的数据，如各类国标码数据、字典数据、权限数据等。对于这类数据，系统采用了缓存预热机制，在系统启动，将这些数据加载到缓存中，后续访问直接获取缓存数据。热点数据指那些用户访问频率最高的数据。对于这类数据，我们在数据查询后，将数据缓存到内存中，在数据有更新时，同步更新缓存数据。通过缓存，满足了系统的查询性能要求。
分布式锁应用方面
在本系统中，为了应用系统数据量添加所带来的系统性能问题，我们对应用做了集群布署。在改善性能的同时，也带来了很多系统功能上的问题。在单体应用中，我们使用了定时任务，用来批处理一些业务功能。比如定时给代表发送节日祝福、生日祝福短信，定时生成数据查询报表等。到了集群环境后，定时任务会在各应用节点重复的执行。这就导致了重复发送短信、重复生成报表等问题。为此，我们使用了reids的setnx和expire功能。在定时任务执行前，让系统的执行线程去执行redis的setnx操作。如果争夺redis锁成功，则本线程定时任务顺利执行，如果争夺失败，则本应用节点的定时任务放弃本次执行。另外，为了保障分布式锁能正确释放，系统使用redis的expire功能，给分布式锁的设置释放时间。保障下次执行定时周期，各线程重新争夺setnx的机会。 通过redis分布式锁的应用，保障了系统在同一时刻有且仅一一个定时任务线程在执行，避免了祝福短信的重复发送和重复生成数据报表的不良后果。
发布订阅应用方面
系统在有些应用方面，要求有较高的吞吐量和顺序处理等方面的要求。比如，系统的消息发送模块，包含系统内消息推送、短信消息、系统业务待办消息等。这些消息面向所有用户，立法、建议提案、履职功作、会议管理等都会涉及大量的消息提醒功能。还有就是在数据使用Excel导入数据库的功能方面。由于单个Excel表的数据有几百行、上千行的数据规模。在并发导入的环境下，一是无法系统无法在第一时间全部处理完成，二是数据要求顺序处理，以满足幂等检查等方面的要求。针对这类情况。我们使用了redis的发布订阅模式。我们将待办消息、短信消息、系统内消息统一写入redi的消息队列中，然后通过redis开发包提供的监听器。异步处理收到的消息。这样，提高了消息处理的吞吐量。在excel导入数据的应用方面。系统首先将解析到的excel数据写入消息队列中。然后通过多线程处理的方式，逐条处理消息中的导入数据。通过redis发布订阅功能的使用，满足了部份功能在吞吐量方面的要求。
通过redis的使用。系统在性能方面有了很大的提升。也满足了功能方面的要求。性能方面，用户登录、热点数据的加载速度、固定数据的加载速度都维护在1秒钟以内，使得用户使用系统的延时感大大降低，功能方面，基本上杜绝了用户重复接收消息、导入数据处理异常等问题。通过这些措施，大大改善了用户体验，得益于此，系统自2021年9月上线以来，一直运行稳定，性能达标，获得了用户的一致好评。
然而，我们在使用redis的过程中，也碰到了不少问题。比如，在使用redis的发布订阅功能时。由于redis只支持广播式的发布功能。也就是说当写入一条消息时，所有应用集群的节点都会收到消息。为此，我们采用了路由键策略。在发送消息时，通过hash计算，随机生成一个匹配路由键。集群中各应用只接固定的路由键。这样，保证了消息只会被一个集群节点接收。另外，在excel导入数据时，经常产生数据丢失的问题。为此，我们采用了在发送数据消息前记录数据条数，处理数据后，记录处理的条数。通过前后数据条数对比，得到excel数据的最终导入情况。再将异常数据反馈给用户重新上传。