JAVAWEB开发之redis学习(十三)——redis服务器的虚拟内存和内存优化

Redis虚拟内存

一、虚拟内存简介：
和大多NoSQL数据库一样，Redis同样遵循了Key/Value数据存储模型。在有些情况下，Redis会将Keys/Values保存在内存中以提高数据查询和数据修改的效率，然而这样的做法并非总是很好的选择。鉴于此，我们可以将之进一步优化，即尽量在内存中只保留Keys的数据，这样可以保证数据检索的效率，而Values数据在很少使用的时候则可以被换出到磁盘。
在实际的应用中，大约只有10%的Keys属于相对比较常用的键，这样Redis就可以通过虚存将其余不常用的Keys和Values换出到磁盘上，而一旦这些被换出的Keys或Values需要被读取时，Redis则将其再次读回到主内存中。
二、虚拟内存应用场景：
对于大多数数据库而言，最为理想的运行方式就是将所有的数据都加载到内存中，而之后的查询操作则可以完全基于内存数据完成。然而在现实中这样的场景却并不普遍，更多的情况则是只有部分数据可以被加载到内存中。
在Redis中，有一个非常重要的概念，即keys一般不会被交换，所以如果你的数据库中有大量的keys，其中每个key仅仅关联很小的value，那么这种场景就不是非常适合使用虚拟内存。如果恰恰相反，数据库中只是包含少量的keys，而每一个key所关联的value却非常大，那么这种场景对于使用虚存就再合适不过了。
在实际的应用中，为了能让虚存更为充分的发挥作用以帮助我们提高系统的运行效率，我们可以将带有很多较小值的Keys合并为带有少量较大值的Keys。其中最主要的方法就是将原有的Key/Value模式改为基于Hash的模式，这样可以让很多原来的Keys成为Hash中的属性。
三、虚拟内存配置：
1). 在配置文件中添加以下配置项，以使当前Redis服务器在启动时打开虚存功能。
vm-enabled yes
2). 在配置文件中设定Redis最大可用的虚存字节数。如果内存中的数据大于该值，则有部分对象被换出到磁盘中，其中被换出对象所占用内存将被释放，直到已用内存小于该值时才停止换出。
vm-max-memory (bytes)
Redis的交换规则是尽量考虑"最老"的数据，即最长时间没有使用的数据将被换出。如果两个对象的age相同，那么Value较大的数据将先被换出。需要注意的是，Redis不会将Keys交换到磁盘，因此如果仅仅keys的数据就已经填满了整个虚存，那么这种数据模型将不适合使用虚存机制，或者是将该值设置的更大，以容纳整个Keys的数据。在实际的应用，如果考虑使用Redis虚拟内存，我们应尽可能的分配更多的内存交给Redis使用，以避免频繁的换入换出。
3). 在配置文件中设定页的数量及每一页所占用的字节数。为了将内存中的数据传送到磁盘上，我们需要使用交换文件。这些文件与数据持久性无关，Redis会在退出前会将它们全部删除。由于对交换文件的访问方式大多为随机访问，因此建议将交换文件存储在固态磁盘上，这样可以大大提高系统的运行效率。
vm-pages 134217728
vm-page-size 32    
在上面的配置中，Redis将交换文件划分为vm-pages个页，其中每个页所占用的字节为vm-page-size，那么Redis最终可用的交换文件大小为：vm-pages * vm-page-size。由于一个value可以存放在一个或多个页上，但是一个页不能持有多个value，鉴于此，我们在设置vm-page-size时需要充分考虑Redis的该特征。
4). 在Redis的配置文件中有一个非常重要的配置参数，即：
vm-max-threads 4
该参数表示Redis在对交换文件执行IO操作时所应用的最大线程数量。通常而言，我们推荐该值等于主机的CPU cores。如果将该值设置为0，那么Redis在与交换文件进行IO交互时，将以同步的方式执行此操作。
对于Redis而言，如果操作交换文件是以同步的方式进行，那么当某一客户端正在访问交换文件中的数据时，其它客户端如果再试图访问交换文件中的数据，该客户端的请求就将被挂起，直到之前的操作结束为止。特别是在相对较慢或较忙的磁盘上读取较大的数据值时，这种阻塞所带来的影响就更为突兀了。然而同步操作也并非一无是处，事实上，从全局执行效率视角来看，同步方式要好于异步方式，毕竟同步方式节省了线程切换、线程间同步，以及线程拉起等操作产生的额外开销。特别是当大部分频繁使用的数据都可以直接从主内存中读取时，同步方式的表现将更为优异。
如果你的现实应用恰恰相反，即有大量的换入换出操作，同时你的系统又有很多的cores，有鉴于此，你又不希望客户端在访问交换文件之前不得不阻塞一小段时间，如果确实是这样，我想异步方式可能更适合于你的系统。
至于最终选用哪种配置方式，最好的答案将来自于不断的实验和调优。

redis服务器内存优化

一、特殊编码：
自从Redis 2.2之后，很多数据类型都可以通过特殊编码的方式来进行存储空间的优化。其中，Hash、List和由Integer组成的Sets都可以通过该方式来优化存储结构，以便占用更少的空间，在有些情况下，可以省去9/10的空间。
这些特殊编码对于Redis的使用而言是完全透明的，事实上，它只是CPU和内存之间的一个交易而言。如果内存使用率方面高一些，那么在操作数据时消耗的CPU自然要多一些，反之亦然。在Redis中提供了一组配置参数用于设置与特殊编码相关的各种阈值，如：
#如果Hash中字段的数量小于参数值，Redis将对该Key的Hash Value采用特殊编码。
hash-max-zipmap-entries 64
#如果Hash中各个字段的最大长度不超过512字节，Redis也将对该Key的Hash Value采用特殊编码方式。
hash-max-zipmap-value 512
#下面两个参数的含义基本等同于上面两个和Hash相关的参数，只是作用的对象类型为List。
list-max-ziplist-entries 512
list-max-ziplist-value 64
#如果set中整型元素的数量不超过512时，Redis将会采用该特殊编码。
set-max-intset-entries 512
倘若某个已经被编码的值再经过修改之后超过了配置信息中的最大限制，那么Redis会自动将其转换为正常编码格式，这一操作是非常快速的，但是如果反过来操作，将一个正常编码的较大值转换为特殊编码，Redis的建议是，在正式做之前最好先简单测试一下转换效率，因为这样的转换往往是非常低效的。
二、BIT和Byte级别的操作：
从Redis 2.2开始，Redis提供了GETRANGE/SETRANGE/GETBIT/SETBIT四个用于字符串类型Key/Value的命令。通过这些命令，我们便可以像操作数组那样来访问String类型的值数据了。比如唯一标识用户身份的ID，可能仅仅是String值的其中一段子字符串。这样就可以通过GETRANGE/SETRANGE命令来方便的提取。再有就是可以使用BITMAP来表示用户的性别信息，如1表示male，0表示female。用这种方式来表示100,000,000个用户的性别信息时，也仅仅占用12MB的存储空间，与此同时，在通过SETBIT/GETBIT命令进行数据遍历也是非常高效的。
三、尽可能使用Hash：
由于小的Hash类型数据占用的空间相对较少，因此我们在实际应用时应该尽可能的考虑使用Hash类型，比如用户的注册信息，这其中包括姓名、性别、email、年龄和口令等字段。我们当然可以将这些信息以Key的形式进行存储，而用户填写的信息则以String Value的形式存储。然而Redis则更为推荐以Hash的形式存储，以上信息则以Field/Value的形式表示。
现在我们就通过学习Redis的存储机制来进一步证明这一说法。在该篇博客的开始处已经提到了特殊编码机制，其中有两个和Hash类型相关的配置参数：hash-max-zipmap-entries和hash-max-zipmap-value。至于它们的作用范围前面已经给出，这里就不再过多的赘述了。现在我们先假设存储在Hash Value中的字段数量小于hash-max-zipmap-entries，而每个元素的长度又同时小于hash-max-zipmap-value。这样每当有新的Hash类型的Key/Value存储时，Redis都会为Hash Value创建定长的空间，最大可预分配的字节数为:
total_bytes = hash-max-zipmap-entries * hash-max-zipmap-value
这样一来，Hash中所有字段的位置已经预留，并且可以像访问数组那样随机的访问Field/Value，他们之间的步长间隔为hash-max-zipmap-value。只有当Hash Value中的字段数量或某一新元素的长度分别超过以上两个参数值时，Redis才会考虑将他们以Hash Table的方式进行重新存储，否则将始终保持这种高效的存储和访问方式。不仅如此，由于每个Key都要存储一些关联的系统信息，如过期时间、LRU等，因此和String类型的Key/Value相比，Hash类型极大的减少了Key的数量(大部分的Key都以Hash字段的形式表示并存储了)，从而进一步优化了存储空间的使用效率。