使用Redis之前个必须了解的事情.docxVIP

使用Redis之前5个必需了解的事情 2021-06-27 使用Redis开发应用程序是一个很开心的过程，但是就像其他技术一样，基于Redis的应用程序设计你同样需要牢记几点。在之前，你可能已经对关系型数据库开发的那一整个套路了然如胸，而基于Redis的应用程序开发也有很多相像的地方，但是你必需牢记以下两点——Redis是个内存数据库，同时它是单线程的。因而，在使用Redis时，你需要留意以下几点： 1. 掌控储存在Redis中的全部键 数据库的次要功能是储存数据，但是对于开发者来说，由于应用程序需求或者数据使用方法的转变，忽视存储在数据库中的某些数据是格外正常的，在Redis中同样如此。你可能忽视期满某些键，也可能由于应用程序的某个模块弃用而忘掉这些数据。 无论哪种情况，Redis都存储了一些不再使用的数据，平白无故的占用了一些空间。Redis的弱结构数据模式让集中储存的内容很难被弄清，除非你为键使用一套格外成熟的命名法则。使用合适的命名方法会简化你的数据库管理，当你通过你的应用程序或者服务做键的命名空间时（通常情况下是使用冒号来划分键名），你就可以在数据迁移、转换或者删除时轻松的识别。 Redis另一个常见用例是作为热数据项作的其次数据存储，大部分的数据被保存在其他的数据库中，比如PostgreSQL或MongoDB。在这些用例中，当数据从主存储移除时，开发者经常会遗忘删除Redis中对应的数据。这种存在跨数据存储的情况下，通常需要做级联删除，这种情况下，可以通过在Redis配置保存特定数据项的全部识别符来实现，从而保证数据在主数据库被删除后，系统会调用一个清理程序来删除全部相关副本和信息。 2. 把握全部键名的长度 在上文我们说过要使用合适的命名规章，并且添加前缀来识别数据走向，因而这一条看起来好像与之违反。但是，请别遗忘，Redis是个内存数据库，键越短你需要的空间就越少。理所当然，当数据库中拥有数百万或者数十亿键时，键名的长度将影响严重。 举个例子：在一个32位的Redis服务器上，假如储存一百万个键，每个值的长度是32-character，那么在使用6-character长度键名时，将会消耗大约96MB的空间，但是假如使用12-character长度的键名时，空间消耗则会提升至111MB左右。随着键的增多，15%的额外开销将产生严重的影响。 3. 使用合适的数据结构 不管是内存使用或者是功能，有的时候数据结构将产生很大的影响，下面是一些可以参考的最佳实践： 取代将数据存储为数千（或者数百万）独立的字符串，可以考虑使用哈希数据结构将相关数据进行分组。哈希表是格外有效率的，并且可以削减你的内存使用；同时，哈希还更无益于细节笼统和代码可读。 合适时候，使用list代替set。假如你不需要使用set特性，List在使用更少内存的情况下可以供应比set更快的速度。 Sorted sets是最昂贵的数据结构，不管是内存消耗还是基本操作的简单性。假如你只是需要一个查询记录的途径，并不在意排序这样的属性，那么轻建议使用哈希表。 Redis中一个经常被忽视的功能就是bitmaps或者bitsets（V2.2之后）。Bitsets允许你在Redis值上执行多个bit-level操作，比如一些轻量级的分析。 4. 使用SCAN时别使用键 从Redis v2.8开头，SCAN命令已经可用，它允许使用游标从keyspace中检索键。对比KEYS命令，虽然SCAN无法一次性前往全部婚配结果，但是却规避了堵塞系统这个高风险，从而也让一些操作可以放在主节点上执行。 需要留意的是，SCAN 命令是一个基于游标的迭代器。SCAN 命令每次被调用之后， 都会向用户前往一个新的游标，用户在下次迭代时需要使用这个新游标作为 SCAN 命令的游标参数， 以此来连续之前的迭代过程。同时，使用SCAN，用户还可以使用keyname模式和count选项对命令进行调整。 SCAN相关命令还包括SSCAN 命令、HSCAN 命令和 ZSCAN 命令，分别用于集合、哈希键及有续集等。 5. 使用服务器端Lua脚本 在Redis使用过程中，Lua脚本的支持无疑给开发者供应一个格外友好的开发环境，从而大幅度解放用户的制造力。假如使用得当，Lua脚本可以给功能和资源消耗带来格外大的改善。取代将数据传送给CPU，脚本允许你在最接近数据的地方执行规律，从而削减网络延时和数据的冗余传输。 在Redis中，Lua一个格外经典的用例就是数据过滤或者将数据聚合到应用程序。通过将处理工作流封装到一个脚本中，你只需要调用它就可以在更短的时间内使用很少的资源来猎取一个更小的答案。