Redis是一個開源的，基于內(nèi)存的結(jié)構(gòu)化數(shù)據(jù)存儲媒介，可以作為數(shù)據(jù)庫、緩存服務(wù)或消息服務(wù)使用。
Redis支持多種數(shù)據(jù)結(jié)構(gòu)，包括字符串、哈希表、鏈表、集合、有序集合、位圖、Hyperloglogs等。
Redis具備LRU淘汰、事務(wù)實現(xiàn)、以及不同級別的硬盤持久化等能力，并且支持副本集和通過Redis Sentinel實現(xiàn)的高可用方案，同時還支持通過Redis Cluster實現(xiàn)的數(shù)據(jù)自動分片能力。Redis的主要功能都基于單線程模型實現(xiàn)，也就是說Redis使用一個線程來服務(wù)所有的客戶端請求，同時Redis采用了非阻塞式IO，并精細地優(yōu)化各種命令的算法時間復雜度。
Redis 作為一個非常成功的數(shù)據(jù)庫，提供了非常豐富的數(shù)據(jù)類型和命令，使用這些，我們可以輕易而高效地完成很多緩存操作，可是總有一些比較特殊問題或需求需要解決，這時候可能就需要我們自己定制自己的 Redis 數(shù)據(jù)結(jié)構(gòu)和命令。
Redis是線程安全的（因為只有一個線程），其所有操作都是原子的，不會因并發(fā)產(chǎn)生數(shù)據(jù)異常。我們都知道 Redis 是單線程的，可是它怎么會有線程安全問題呢？
?Redis 的線程安全問題的產(chǎn)生，并不是來自于 Redis 服務(wù)器內(nèi)部。Redis 作為數(shù)據(jù)服務(wù)器，就相當于多個客戶端的共享內(nèi)存，多個客戶端就相當于同一進程下的多個線程，如果多個客戶端之間沒有良好的數(shù)據(jù)同步策略，就會產(chǎn)生類似線程安全的問題。
典型場景是：
? Redis 內(nèi)存儲了一個用戶的狀態(tài)：user5277=idle；
? 客戶端連接 A 讀取了用戶狀態(tài)，獲取到用戶的空閑狀態(tài) status = get("user5277")；
? 客戶端連接 B 也同樣讀取了用戶狀態(tài)；
? 客戶端連接 A 給用戶安排了一個任務(wù)，并將 Redis 內(nèi)用戶狀態(tài)置為忙碌 set("user5277", "busy")；
? 客戶端連接 B 同樣設(shè)置用戶為忙碌狀態(tài)。
? 可是此時用戶卻被同時分配了兩個任務(wù)。
導致這個問題的原因就是雖然 Redis 是單線程的，能保證命令的序列化，但由于其執(zhí)行效率很高，多個客戶端的命令之間不做好請求同步，同樣會造成命令的順序錯亂。
當然這個問題也很好解決，給用戶狀態(tài)加鎖就行了，使同一時間內(nèi)只能有一個客戶端操作用戶狀態(tài)。不過加鎖我們就需要考慮鎖粒度、死鎖等問題了，無疑添加了程序的復雜性，不利于維護。
新網(wǎng)云數(shù)據(jù)庫Redis專有網(wǎng)絡(luò)VPC在TCP層直接進行網(wǎng)絡(luò)隔離保護；內(nèi)存加硬盤的混合存儲方式，在提供高速數(shù)據(jù)讀寫能力的同時滿足數(shù)據(jù)持久化需求，支持單節(jié)點架構(gòu)、主從架構(gòu)、分布式集群架構(gòu)，滿足純緩存場景、讀寫分離、隨時需要擴展數(shù)據(jù)庫性能等不同的業(yè)務(wù)需求，可根據(jù)業(yè)務(wù)需求對集群進行升配、擴容等操作，集群版支持增加主節(jié)點，實現(xiàn)云上資源彈性擴展：http://www.xinnet.com/cs/redis.html