聊聊 Redis 性能细节
source link: https://mp.weixin.qq.com/s/8QUZl_S-_zq_3usRsQWW5A?amp%3Butm_medium=referral
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
聊聊内存存储，redis作为分布式内存缓存，性能极高，但是在高并发读、高并发、大存储量写的场景下很多东西要注意，不然可能达不到预想性能效果。不能用透明方式去使用，而应该多去了解架构以及具体实现。不去了解细节，在高压力应用下，可能会对线上服务造成很大影响，达不到高可用。
关于数据结构，数据结构redis支持很多种，现在要探讨一件事不是这么多种数据结构，而是在高并发场景下，尽量避免用哪些数据结构，尽量多用哪些数据结构，尽量避免应用数据结构是hash，包含set以及map，因为hash结构复杂既需要更大存储空间，也需要更多计算才能将数据取出。
举个以前线上遇到过的问题，就是线上用了很多set，因为在一些场景下过滤等等逻辑，用set很方面，但是却对redis server不友好，对redis server压力大。
线上还遇到过，定时拉取过多会导致tp999上升影响接口正常使用，这时就需要降低对于redis过于多的批量读取，方式就是暂时减少redis server的压力，等待redis server恢复正常后，拉取是没有问题的，但后续还是要优化，尽量避免压力过大。
线上还发生过单个大key对线上，直接在一个时间点服务突然性能就变得很低，并且每5分钟一次，经定位是一个数据过大并且是通用数据，定时拉取每次定时拉取时整个redis集群堵住，导致集群吞吐下降tp99升高。
反推过去看是越小越好，批量夺取越小tp999会变得越小，他是一个动态服务，很难界定一个值多大为好。这就需要线上常年经验积累以及对于线上问题不断反思以及调整。
所有办法都想了，对于存储以及db架构，原理实现都有了解了就能避免问题吗？答案是不一定，通过我们对架构理解能解决一部分问题，但还是有一些问题没有了解到的，或是想不到的，这就需要我们有意外时备选方案，已做到我们能想到的万无一失。
备选方案具体思路就是减少或者避免对redis依赖，通过本地内存来提供业务需要数据，切断对redis依赖，避免因为redis性能波动导致线上业务性能波动，或者因为redis集群出现比较严重问题，主从断开、性能及其突然严重下跌，或者集群不稳定，这些是比较极端情况，虽然很少遇到，属于“黑天鹅”事件，但发生了会对线上业务有极大影响，一定要避免。
降级备选方案，在redis出现严重问题时启用，可以采取基于zookeeper配置中心方式实现，通过配置下发来达到秒级降级，避免对线上业务造成影响，备选方案极其重要不可轻视。从根本上应该是想办法让线上服务读的单个数据尽可能小，批量数据尽可能少，这样就能让tp999越来越高，离线计算、准实时以及其他存储应用是值得去不断探索的。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK