聊聊内存存储，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越来越高，离线计算、准实时以及其他存储应用是值得去不断探索的。
