IT主题的小型文献综述

Redis数据库文献综述

摘 要：本文介绍文献综述的技巧，并进行分析。在此基础上，再将这几种技巧方法结合实际写作进行简要分析。从文献综述的写作目的和常见问题入手介绍文献综述写作需要避免的问题，以及突出展示论文的注释书目写作的关键技巧和心得。关键词：文献综述；论文写作

引言
科学写作的方法有许多，从文献综述的角度进行分析比如，从论文如何突出创新性的角度，还有论文的取材有 道和注释书目的写作的技巧方面等。如何对文献综述内容进行组织，我们需要知道如何进行文献综述的常用问题和一 般步骤。如何强化文献论述，提出自己的结论或者观点主张。我们都知道学术写作的论文综述有诸多要求，我们写作过程中要贴 近这些要求来写，而不是偏离了这些基本要求。
1文献综述的作用和举例
1.1论文文献综述的作用

学术论文的文献综述要针对某个研究主题[1]，就目前学术界的成果加以探究。文献综述旨在整合此研究主题 的特定领域中已经被思考过与研究过的信息，并将此议题上的权威学者所作的努力进行系统地展现、归纳和评述。

怎么让读者熟悉现有的研究主题领域中有关研究的进展和困境，提供后续研究者的思考，未来研究是否可以 提出更加显著的结果，对各种理论的立场说明，可以提出不同的概念架构，作为新假设提出与研究理论的基础，改进和 批判现有的研究的不足，另外推出另类研究，发掘新的研究的方法和研究，验证了现有的相关研究。

1.1.1文献综述的作用
文献综述的创新性和先进性，旨在说明本研究是有创造性地提出了改进和开拓[2]。

综述文章，一部分是综合别人的工作，另一部分，还在于论述自己的观点。这只是综合的一步，应该更进一步， 要能发现新的问题、新的优点或者缺点、提出改进方法，以及对未来工作和发展前景的建议和设想，更有甚者，跳出对原有实验细枝末节的讨论，从一个更高的水平，从原理上、方法论上和系统性上加以评价。这当然很难，故而，多 数综述文章综而不述，让读者看完之后，对过去有些了解，对未来仍是茫然。当然，论述的越多，耗费的时间和精力越大。 鲜明的例子是，某些大师增删二十多次才写出为未来多年的发展方向提出自己独到的见解的文章，方知“述”之不易。
1.2论文综述举例

Redis作为数据库会有许多地方应用[3]，首先Redis作为非关系型数据库的应用，我们在李磊发表的《基于Redis的微博系统基本功能设计》[4]，不难看出，因为Redis作为非关系型数据库有着得天独厚的优势，对比在其他数据库比如Memcached。Redis可能在一些场景和Memcached不相上下,比如在Blog和BBS的应用中，比如新浪微博我们通常采用这种Memcacehd的这种模式，而BBS中需要记录的在线人数，在线用户等场景也应用到此技术。
这些频繁使用小数据的处理非常的繁琐，而Memcached在这种场景下可以避免数据库冗余字段的添加，只需要定期

持久化就可以了。Redis将数据保存在内存里面，新浪微博就大量采用这种模式来存储用户关系和计数，如果仅仅采用关系型数据库的话，微博用户每时每刻都可能会有成百万级别的信息发送微博，如果仅仅靠横向拓展增加服务器的模式 来肯定是不行的，因为一台服务器最多可能支持的数据规模也就几千万，因此，目前新浪就是在采用Redis，还有在一些行业的快递公司，也在使用这种模式做查询接口。
Redis的出现很大程度弥补了Memcached的键值存储的不足，在有些场合可以很好的和Memcached形成互补，甚至取代。 Redis作为微博系统中常见的键值对存储方式，在微博架构中的角色对象中，对于大型的微博系统，如果在数据量大的
情况下，上述的消息数据的键值对可以进行更细致的划分。比如Redis本身是有过期时间的机制的，当前内存中的部分数据可以存在过期的控制，如果有一部分微博消息是已经处于不太活跃的状态，可以通过时间筛选，将其换出内存。同 样对于部分用户，如果在长期处于不活动的状态，他的相关消息也可以滞后读取。此外,当微博的消息中加入了大量的视频，图像和音频后,这些惰性的媒体数据的保存可以有效避免数据的堆积而导致搜素效率下降，保证在 Redis 数据中只保存相关的索引。在这样的情况下，Redis 可以充分发挥它的索引和查询机制[5]。
Redis作为缓存，可以说是最常见的应用：比如在没有使用缓存的时候，我们要查询用户信息直接查询MysqlDB，但是如果采用了Redis做缓存，过程就是这样，当用客户端调用getUser接口查询用户信息的时候，getUser接口直接去Redis中查询，查询结果无非两种情况有和没有，如果Redis中有该用户信息[5]，直接返回，避免查询MySQL，从而避免了 磁盘IO操作（我们都知道比起操作内存，操作磁盘的效率比较低）；另一种情形Redis中没有该用户信息，则从MySQL查询，并且把该用户信息存放到Redis中一份；这样下次去Redis中查询就有了。但是，在服务接口（getUser）和DB中间， 增加了一个缓存层,这看似是逻辑增加了变麻烦了。但是，当面对高并发的时候，只有第一次查询有磁盘IO操作，以后只要Redis中存在就没必要再查询数据库了，其实是提高了效率。
这种被大家熟知的缓存模式其实是有一点小问题的，比如，假设删除了缓存Redis中小明这名学员的信息，但是还 没有来急删除MySQL中对应的小明这条信息，此时，另一个线程来查询小明这条信息了，结果先读取Redis缓存因为我删了小明所以为没有此人信息，但是按照流程去MySQL中查询到了小明的数据(注意，此时小明这条数据本来应该删除的但是没来得及删除)于是就又将小明写入缓存，此时缓存中出现了一条刚才删除的小明数据。面对这种先操作缓存，在写数据库成功之前，如果有读请求发生，可能导致旧数据入缓存，引发数据不一致的问题[6]，目前有3种比较成熟的解决 方案：第一，双删延迟：删除两次缓存，中间延迟一段时间：这么操作，可以将1秒内所造成的缓存脏数据，再次删除。 第二，串行化 我们利用MQ将所有“读数据库” 和“写缓存”的步骤串行化采用消费队列保证一致性。第三，使用Canal解析binlog 日志，Mysql通过binlog同步redis，我个人推荐使用第3种，我附上了流程图供大家参考。这里的Canal还可以用于其他数据的同步，比如ElasticSearch和Mysql的同步。总结一下：无论采用哪种策略，都以保障redis 和mysql数据要在大部分时段内保持一致，一旦一致就延续这种一致性不变为目标。
Redis作为消息队列的情形，我们都知道，Redis的5种基本数据类型有字符串，散列hash，列表list，集合 set，有序集合sortedset，其中如果对list类型稍有熟悉的同学都知道这是一种“链表”数据类型，链表就像一节一节火车车厢，既然是火车就有车头车尾，作为消息队列的时候，假设我们只从车头处加车厢，并且只从车尾处卸下车厢，这样就 保证是一个first in first out（FIFO）有序的队列，即，最先加的车厢最先卸下，也就保证了消息的有序一致性，消息生产者从链表一端push推数据，消费者监听这个list并且定时从另一端pop拉数据，这样就完成了Redis作为点对点队列，广播订阅方式同样的道理，通过Redis消息监听器容器可以添加多个监听话题的，把消息监听器和相应的消息订阅

处理器绑定就可以实现，另外，对比主流队列RabbitMQ和Kafka的重量级和大吞吐量,Redis一般用于轻量，实时性要求高 的情况。
Redis作为分布式锁有以下几种应用：首先 setnx这个命令，如果返回0，则该锁正在被别人使用，返回1则成功获取锁，还设置一个获取的超时时间。所以我们在应用redis获取锁的时候，用 setnx 加锁，key为被锁的数据的唯一标识，value为当前服务器ip和任务标识的拼接（实际可以调整具体含义），在释放锁的时候进行判断。并用expire命令 为锁添加过期时间，超过该时间则自动释放锁.。释放锁的时候，判断是不是该锁，若是，则执行 delete 进行释放。
Redis作为计数器，主键生成器，我们知道Id主键生成都有以下几种常见的方式[7]：
1.数据库的自增ID：需要有一个唯一ID来标识一条数据或消息，一旦分表分库数据库的自增ID显然不能满足需求；
2.UUID不易于存储：UUID太长，16字节128位，很多场景不适用；
3.SNOWFLAKE算法由于其强依赖机器时钟，其中一部分序号如果用完了，这个单位时间就不能再生成序号了；
Redis作为Id生成中心，因为redis有时间，和自增的命令，所以程序用到生成主键的时候就都从id生成中心中取新 生成的id，这样生产的id 唯一并且依赖事件，保证了不会冲突。这个有点像我们去银行办理业务的时候，有个大堂经理让我们取号，取号机就想id生成器一样，保证每次叫号不会冲突。
Redis出现雪崩[8]，缓存雪崩通俗简单的理解就是：由于原有缓存失效（或者数据未加载到缓存中），新缓存未到期 间（缓存正常从Redis中获取）所有原本应该访问缓存的请求都去查询数据库了，而对数据库CPU和内存造成巨大压力， 严重的会造成数据库宕机，造成系统的崩溃。缓存失效时的雪崩效应对底层系统的冲击非常可怕！那有什么办法来解决 这个问题呢？基本解决思路如下：第一，大多数系统设计者考虑用加锁或者队列的方式保证来保证不会有大量的线程对 数据库一次性进行读写，避免缓存失效时对数据库造成太大的压力，虽然能够在一定的程度上缓解了数据库的压力但是 与此同时又降低了系统的吞吐量。第二，分析用户的行为，尽量让缓存失效的时间均匀分布。第三，如果是因为某台缓 存服务器宕机，可以考虑做主备，比如：redis主备，但是双缓存涉及到更新事务的问题，update可能读到脏数据，需要好好解决。
胡雅倩在《基于Redis限制用户访问频率的研究》论文中提到[9]：在Web系统开发中常常会遇到需要限制某些接口 访问频率的情况。例如限制用户登录频率,限制用户发帖、点赞、回复的频率等。针对此类场景,本文深入研究并总结了 当前两种使用Redis限制用户访问频率的主流方式——队列和滑动窗口,并对每种方式的实现原理和Java语言实现过程进 行了详细阐述，缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，如发起为id为“-1”的数据或id为 特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大。解决方案：接口层增加校验，如用户 鉴权校验，id做基础校验，id<=0的直接拦截；从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value 对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个id暴力攻击。
缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没 读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力。解决方案和：设置热点数据永远不过 期。加互斥锁[10][11]。
未来的研究展望，可以研究出一种兼顾非关系型数据库和关系型数据库优点的一种数据库[12]。
2结语

根据以上讨论的结果，我以Redis数据库这个IT领域近乎长久不衰的主题进行文献综述的举例，我们总结一下，如何 提高论文书写质量，如何才能把文献综述和注释书目的技巧进行提高，这些看似简单的技巧文献综述的技巧和步骤，如何 在论文的编写中灵活运用，触类旁通。需要我们反反复复的练习和琢磨，文献综述的技巧的学习非一日之功，而是在平时的 学术论文习作中不断运用，不断总结方可掌握的。以上讨论的一些技巧只是抛砖引玉，论文写作技巧实在太丰富，和博大精 深了，需要后面不断补充的学习。

参考文献

[1]陈云霞,刘永慧,杨洪刚.线上教学背景下如何提升硕士研究生文献综述的撰写能力[J].科教文汇(下旬 刊),2021(04):20-21.
[2]冯光财, 戴吾蛟, 吴芳. 测绘科学研究生文献综述写作能力培养探讨[ J]. 测绘与空间地理信息,2021 , 44 ( 03 ): 4 - 6 .
[3]桂成杰, 曾献辉. 结合Redis与Web Socket的智能空调移动环境实时控制技术[J]. 软件导刊,2020 , 19 ( 01 ): 190 - 194 .
[4]李磊.基于Redis的微博系统基本功能设计[J].电脑知识与技术,2016,12(25):61-63.
[5]王心妍.Memcached和Redis在高速缓存方面的应用[J].无线互联科技,2012(09):8-9.
[6]唐诚.Redis数据库在微博系统中的实践[J].厦门城市职业学院学报,2012,14(03):55-59.
[7]王艳,董丽丽.NoSQL与关系数据库相结合的设计与实践[J].电脑知识与技术,2014,10(09):1857-1859.
[8]韩君易.基于电子商务平台的NoSQL解决方案应用研究[J].科技信息,2011(20):629+632.
[9]胡雅倩.基于Redis限制用户访问频率的研究[J].网络新媒体技术,2020,9(06):21-25+50.
[10]伍华锋,王小刚,候劲,唐小林.Redis集群系统的优化研究与实现[J].四川轻化工大学学报(自然科学 版),2020,33(06):39-45.
[11]郭淑菊,蒋可心,侯博,宋娟,葛冰儿,李如伟. 基于Redis的分布式高精度位置服务平台设计与实现[A]. 中国卫星导航系统管理办公室学术交流中心.第十二届中国卫星导航年会论文集——S02 导航与位置服务[C].中国卫星导航系统管理办公室学术交流中心:中国卫星导航学术年会组委会,2021:5.
[12]秦溧,艾青.基于Redis技术的页面缓存研究[J].科技风,2021(12):74-76.