1. Algunas sugerencias para la optimización
1. Intenta usar una tecla corta
Por supuesto, mientras simplifica, no "vea el nombre y sepa el significado" de la clave. Algunos valores también se pueden simplificar, como usar 0 y 1 para el género.
2. Evita el uso de llaves*
keys *, este comando es de bloqueo, es decir, durante la ejecución de la operación, no se pueden ejecutar otros comandos en su instancia. Cuando la cantidad de datos clave en redis es tan pequeña que no importa, es muy malo si la cantidad de datos es grande. Así que debemos evitar usar este comando. Puede usar ESCANEAR en su lugar.
3. Comprima sus datos antes de almacenarlos en Redis
Redis proporciona dos métodos de codificación internos para cada tipo de datos y ajustará automáticamente el método de codificación adecuado en diferentes circunstancias.
4. Establecer el período de validez de la clave
Deberíamos hacer uso del período de validez de la clave tanto como sea posible. Por ejemplo, algunos datos temporales (código de verificación de SMS), después del período de validez, ¡Redis los borrará automáticamente!
5. Selecciona la estrategia de reciclaje (maxmemory-policy)
Cuando el espacio de la instancia de Redis esté lleno, intentará recuperar algunas claves. Dependiendo de cómo lo use, se recomienda encarecidamente usar la estrategia volatile-lru (predeterminada), siempre que haya establecido un tiempo de espera para la clave. Pero si está ejecutando algo similar al caché y no ha establecido un mecanismo de tiempo de espera para la clave, puede considerar usar el mecanismo de reciclaje allkeys-lru y explicarlo en detalle. maxmemory-samples 3 significa que cada vez que se realice la eliminación, se seleccionarán aleatoriamente 3 claves para eliminar las menos usadas (opción por defecto).
1 2 3 4 5 6 7 |
maxmemory-policy seis maneras: volatile-lru: solo realice LRU en claves con tiempo de caducidad establecido (valor predeterminado) allkeys-lru: para eliminar las claves de uso poco frecuente de todas las claves volatile-random: elimina aleatoriamente las claves que están a punto de caducar allkeys-random: eliminar al azar volatile-ttl: eliminar la expiración noeviction: nunca caduca, devuelve un error |
6. Use operaciones a nivel de bits y operaciones a nivel de bytes para reducir el uso innecesario de la memoria
1 2 |
Operaciones a nivel de bits: GETRANGE, SETRANGE, GETBIT y SETBIT byte operaciones a nivel de byte: GETRANGE y SETRANGE |
7. Usa hash tanto como sea posible para el almacenamiento de hash
8. Cuando el escenario empresarial no requiera persistencia de datos, apague todos los métodos de persistencia para obtener el mejor rendimiento
La persistencia de datos requiere un compromiso entre persistencia y latencia/rendimiento.
9. Puede usar canalizaciones cuando desee agregar varios datos a la vez
10. Limite el tamaño de la memoria de redis (el sistema de 64 bits no limita la memoria y el sistema de 32 bits utiliza hasta 3 GB de memoria de forma predeterminada)
Si la cantidad de datos es impredecible y la memoria es limitada, intente limitar el tamaño de la memoria utilizada por redis, para evitar que redis use particiones de intercambio o errores OOM. (El uso de la partición de intercambio tiene un bajo rendimiento. Si la memoria es limitada, no se pueden agregar datos después de alcanzar la memoria especificada; de lo contrario, se informará un error OOM. Puede configurar maxmemory-policy para eliminar datos cuando la memoria es insuficiente)
11, SLOWLOG [get/reset/len]
1 2 |
slowlog-log-slower-than Decide grabar comandos cuyo tiempo de ejecución es mayor a cuantos microsegundos (microsegundo, 1 segundo = 1,000,000 microsegundos). slowlog-max-len Determina la cantidad máxima de registros que puede guardar slowlog.Cuando encuentre que el rendimiento de redis está degradado, puede verificar qué comandos lo están causando. |
2. Prueba de tubería
La función de canalización de redis no está disponible en la línea de comandos, pero redis admite canalizaciones y se puede usar en el cliente java (jedis):
Código de muestra:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 dieciséis 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
//Nota: El consumo de tiempo específico está relacionado con su propia computadora (el blogger son los datos que se ejecutan en la máquina virtual) /** * Inicializar piezas de datos de 1W sin usar canalizaciones * Consumo de tiempo: 3079 milisegundos * Excepción @throws */ @Prueba public void NOTUsePipeline() arroja una excepción { Jedis jedis = JedisUtil.getJedis(); long start_time = System.currentTimeMillis(); for (int i = 0; i < 10000; i++) { jedis.set("aa_"+i, i+""); } System.out.println(System.currentTimeMillis()-start_time); }
/** * 使用管道初始化1W条数据 * 耗时：255毫秒 * @throws Exception */ @Test public void usePipeline() throws Exception { Jedis jedis = JedisUtil.getJedis();
long start_time = System.currentTimeMillis(); Pipeline pipelined = jedis.pipelined(); for (int i = 0; i < 10000; i++) { pipelined.set("cc_"+i, i+""); } pipelined.sync();//执行管道中的命令 System.out.println(System.currentTimeMillis()-start_time); } |
hash的应用
示例：
COC中每个客户会对应上千个标签，每个客户就是一个对象，我们如何存储它？
这里写图片描述
存储结构比较：
序列化对象：要求在redis存储前对象进行序列化操作，每次取出后还要执行反序列化操作，开销太大；如果只想取对象的某一个值，都需要将整个对象取出，还要解决并发、数据一致性、加锁等复杂问题。
K-V模式: phone字段冗余；
HASHMAP: phone字段只出现一次，避免数据冗余。
Instagram内存优化
Instagram可能大家都已熟悉，当前火热的拍照App，月活跃用户3亿。四年前Instagram所存图片3亿多时需要解决一个问题：想知道每一张照片的作者是谁（通过图片ID反查用户UID），并且要求查询速度要相当的块，如果把它放到内存中使用String结构做key-value:
1 2 3 |
HSET "mediabucket:1155" "1155315" "939" HGET "mediabucket:1155" "1155315" "939" |
测试：1百万数据会用掉70MB内存，3亿张照片就会用掉21GB的内存。当时(四年前)最好是一台EC2的 high-memory 机型就能存储（17GB或者34GB的，68GB的太浪费了）,想把它放到16G机型中还是不行的。
Instagram的开发者向Redis的开发者之一Pieter Noordhuis询问优化方案，得到的回复是使用Hash结构。具体的做法就是将数据分段，每一段使用一个Hash结构存储.
由于Hash结构会在单个Hash元素在不足一定数量时进行压缩存储，所以可以大量节约内存。这一点在上面的String结构里是不存在的。而这个一定数量是由配置文件中的hash-zipmap-max-entries参数来控制的。经过实验，将hash-zipmap-max-entries设置为1000时，性能比较好，超过1000后HSET命令就会导致CPU消耗变得非常大。
1 2 3 |
HSET "mediabucket:1155" "1155315" "939" HGET "mediabucket:1155" "1155315" "939" |
测试：1百万消耗16MB的内存。总内存使用也降到了5GB。当然我们还可以优化，去掉mediabucket:key长度减少了12个字节。
1 2 3 |
HSET "1155" "315" "939" HGET "1155" "315" "939" |
三、优化案例
1、修改linux中TCP监听的最大容纳数量
1 2 |
WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128. |
在高并发环境下你需要一个高backlog值来避免慢客户端连接问题。注意Linux内核默默地将这个值减小到/proc/sys/net/core/somaxconn的值，所以需要确认增大somaxconn和tcp_max_syn_backlog两个值来达到想要的效果。
echo 511 > /proc/sys/net/core/somaxconn
注意：这个参数并不是限制redis的最大链接数。如果想限制redis的最大连接数需要修改maxclients，默认最大连接数为10000
2、修改linux内核内存分配策略
1 2 3 |
错误日志：WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1 |
redis在备份数据的时候，会fork出一个子进程，理论上child进程所占用的内存和parent是一样的，比如parent占用的内存为8G，这个时候也要同样分配8G的内存给child,如果内存无法负担，往往会造成redis服务器的down机或者IO负载过高，效率下降。所以内存分配策略应该设置为 1（表示内核允许分配所有的物理内存，而不管当前的内存状态如何）。
内存分配策略有三种
可选值：0、1、2。
0， 表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用进程。
1， 不管需要多少内存，都允许申请。
2， 只允许分配物理内存和交换内存的大小(交换内存一般是物理内存的一半)。
3、关闭Transparent Huge Pages(THP)
THP会造成内存锁影响redis性能，建议关闭
1 2 3 4 |
Transparent HugePages ：用来提高内存管理的性能 Transparent Huge Pages在32位的RHEL 6中是不支持的 执行命令 echo never > /sys/kernel/mm/transparent_hugepage/enabled 把这条命令添加到这个文件中/etc/rc.local |