Redis是什么，用來(lái)做什么

Redis是一個(gè)nosql數(shù)據(jù)庫(kù)，可以存儲(chǔ)key-value值。因?yàn)槠涞讓訉?shí)現(xiàn)中，數(shù)據(jù)讀寫(xiě)是基于內(nèi)存，速度非常快，所以常用于緩存；進(jìn)而因其為獨(dú)立部署的中間件，常用于分布式緩存的實(shí)現(xiàn)方案。

成都創(chuàng)新互聯(lián)專注于長(zhǎng)泰企業(yè)網(wǎng)站建設(shè),自適應(yīng)網(wǎng)站建設(shè),商城網(wǎng)站建設(shè)。長(zhǎng)泰網(wǎng)站建設(shè)公司,為長(zhǎng)泰等地區(qū)提供建站服務(wù)。全流程按需網(wǎng)站開(kāi)發(fā)，專業(yè)設(shè)計(jì)，全程項(xiàng)目跟蹤，成都創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務(wù)

常用場(chǎng)景有：緩存、秒殺控制、分布式鎖。

雖然其是基于內(nèi)存讀寫(xiě)，但底層也有持久化機(jī)制；同時(shí)具備集群模式；不用擔(dān)心其可用性。

關(guān)于Redis的使用，可以參考《Redis的使用方法、常見(jiàn)應(yīng)用場(chǎng)景》

有哪些輕型的非關(guān)系型數(shù)據(jù)庫(kù)？

常見(jiàn)的非關(guān)系型數(shù)據(jù)庫(kù)有：1、mongodb；2、cassandra；3、redis；4、hbase；5、neo4j。其中mongodb是非常著名的NoSQL數(shù)據(jù)庫(kù)，它是一個(gè)面向文檔的開(kāi)源數(shù)據(jù)庫(kù)。

常見(jiàn)的幾種非關(guān)系型數(shù)據(jù)庫(kù)：

1、MongoDB

MongoDB是最著名的NoSQL數(shù)據(jù)庫(kù)。它是一個(gè)面向文檔的開(kāi)源數(shù)據(jù)庫(kù)。MongoDB是一個(gè)可伸縮和可訪問(wèn)的數(shù)據(jù)庫(kù)。它在c++中。MongoDB同樣可以用作文件系統(tǒng)。在MongoDB中，JavaScript可以作為查詢語(yǔ)言使用。通過(guò)使用sharding MongoDB水平伸縮。它在流行的JavaScript框架中非常有用。

人們真的很享受分片、高級(jí)文本搜索、gridFS和map-reduce功能。驚人的性能和新特性使這個(gè)NoSQL數(shù)據(jù)庫(kù)在我們的列表中名列第一。

特點(diǎn)：提供高性能；自動(dòng)分片；運(yùn)行在多個(gè)服務(wù)器上；支持主從復(fù)制；數(shù)據(jù)以JSON樣式文檔的形式存儲(chǔ)；索引文檔中的任何字段；由于數(shù)據(jù)被放置在碎片中，所以它具有自動(dòng)負(fù)載平衡配置；支持正則表達(dá)式搜索；在失敗的情況下易于管理。

優(yōu)點(diǎn)：易于安裝MongoDB；MongoDB Inc.為客戶提供專業(yè)支持；支持臨時(shí)查詢；高速數(shù)據(jù)庫(kù)；無(wú)模式數(shù)據(jù)庫(kù)；橫向擴(kuò)展數(shù)據(jù)庫(kù)；性能非常高。

缺點(diǎn)：不支持連接；數(shù)據(jù)量大；嵌套文檔是有限的；增加不必要的內(nèi)存使用。

2、Cassandra

Cassandra是Facebook為收件箱搜索開(kāi)發(fā)的。Cassandra是一個(gè)用于處理大量結(jié)構(gòu)化數(shù)據(jù)的分布式數(shù)據(jù)存儲(chǔ)系統(tǒng)。通常，這些數(shù)據(jù)分布在許多普通服務(wù)器上。您還可以添加數(shù)據(jù)存儲(chǔ)容量，使您的服務(wù)保持在線，您可以輕松地完成這項(xiàng)任務(wù)。由于集群中的所有節(jié)點(diǎn)都是相同的，因此不需要處理復(fù)雜的配置。

Cassandra是用Java編寫(xiě)的。Cassandra查詢語(yǔ)言(CQL)是查詢Cassandra數(shù)據(jù)庫(kù)的一種類(lèi)似sql的語(yǔ)言。因此，Cassandra在最佳開(kāi)源數(shù)據(jù)庫(kù)中排名第二。Facebook、Twitter、思科(Cisco)、Rackspace、eBay、Twitter、Netflix等一些最大的公司都在使用Cassandra。

特點(diǎn)：線性可伸縮；；保持快速響應(yīng)時(shí)間；支持原子性、一致性、隔離性和耐久性(ACID)等屬性；使用Apache Hadoop支持MapReduce；分配數(shù)據(jù)的最大靈活性；高度可伸縮；點(diǎn)對(duì)點(diǎn)架構(gòu)。

優(yōu)點(diǎn)：高度可伸縮；無(wú)單點(diǎn)故障；Multi-DC復(fù)制；與其他基于JVM的應(yīng)用程序緊密集成；更適合多數(shù)據(jù)中心部署、冗余、故障轉(zhuǎn)移和災(zāi)難恢復(fù)。

缺點(diǎn)：對(duì)聚合的有限支持；不可預(yù)知的性能；不支持特別查詢。

3、Redis

Redis是一個(gè)鍵值存儲(chǔ)。此外，它是最著名的鍵值存儲(chǔ)。Redis支持一些c++、PHP、Ruby、Python、Perl、Scala等等。Redis是用C語(yǔ)言編寫(xiě)的。此外，它是根據(jù)BSD授權(quán)的。

特點(diǎn)：自動(dòng)故障轉(zhuǎn)移；將其數(shù)據(jù)庫(kù)完全保存在內(nèi)存中；事務(wù)；Lua腳本；將數(shù)據(jù)復(fù)制到任意數(shù)量的從屬服務(wù)器；鑰匙的壽命有限；LRU驅(qū)逐鑰匙；支持發(fā)布/訂閱。

優(yōu)點(diǎn)：支持多種數(shù)據(jù)類(lèi)型；很容易安裝；非常快（每秒執(zhí)行約11萬(wàn)組，每秒執(zhí)行約81000次）；操作都是原子的；多用途工具（在許多用例中使用）。

缺點(diǎn)：不支持連接；存儲(chǔ)過(guò)程所需的Lua知識(shí)；數(shù)據(jù)集必須很好地適應(yīng)內(nèi)存。

4、HBase

HBase是一個(gè)分布式的、面向列的開(kāi)源數(shù)據(jù)庫(kù)，該技術(shù)來(lái)源于 Fay Chang 所撰寫(xiě)的Google論文“Bigtable：一個(gè)結(jié)構(gòu)化數(shù)據(jù)的分布式存儲(chǔ)系統(tǒng)”。就像Bigtable利用了Google文件系統(tǒng)（File System）所提供的分布式數(shù)據(jù)存儲(chǔ)一樣，HBase在Hadoop之上提供了類(lèi)似于Bigtable的能力。

HBase是Apache的Hadoop項(xiàng)目的子項(xiàng)目。HBase不同于一般的關(guān)系數(shù)據(jù)庫(kù)，它是一個(gè)適合于非結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)的數(shù)據(jù)庫(kù)。另一個(gè)不同的是HBase基于列的而不是基于行的模式。

5、neo4j

Neo4j被稱為原生圖數(shù)據(jù)庫(kù)，因?yàn)樗行У貙?shí)現(xiàn)了屬性圖模型，一直到存儲(chǔ)層。這意味著數(shù)據(jù)完全按照白板的方式存儲(chǔ)，數(shù)據(jù)庫(kù)使用指針導(dǎo)航和遍歷圖。Neo4j有數(shù)據(jù)庫(kù)的社區(qū)版和企業(yè)版。企業(yè)版包括Community Edition必須提供的所有功能，以及額外的企業(yè)需求，如備份、集群和故障轉(zhuǎn)移功能。

特點(diǎn)：它支持唯一的約束；Neo4j支持完整的ACID(原子性、一致性、隔離性和持久性)規(guī)則；Java API: Cypher API和本機(jī)Java API；使用Apache Lucence索引；簡(jiǎn)單查詢語(yǔ)言Neo4j CQL；包含用于執(zhí)行CQL命令的UI: Neo4j Data Browser。

優(yōu)點(diǎn)：容易檢索其相鄰節(jié)點(diǎn)或關(guān)系細(xì)節(jié)，無(wú)需連接或索引；易于學(xué)習(xí)Neo4j CQL查詢語(yǔ)言命令；不需要復(fù)雜的連接來(lái)檢索數(shù)據(jù)；非常容易地表示半結(jié)構(gòu)化數(shù)據(jù)；大型企業(yè)實(shí)時(shí)應(yīng)用程序的高可用性；簡(jiǎn)化的調(diào)優(yōu)。

缺點(diǎn)：不支持分片

網(wǎng)易傳媒技術(shù)團(tuán)隊(duì)：消息中間件實(shí)現(xiàn)延遲隊(duì)列的應(yīng)用與實(shí)踐

早期需要延遲處理的業(yè)務(wù)場(chǎng)景，更多的是通過(guò)定時(shí)任務(wù)掃表，然后執(zhí)行滿足條件的記錄，具有頻率高、命中低、資源消耗大的缺點(diǎn)。隨著消息中間件的普及，延遲消息可以很好的處理這種場(chǎng)景，本文主要介紹延遲消息的使用場(chǎng)景以及基于常見(jiàn)的消息中間件如何實(shí)現(xiàn)延遲隊(duì)列，最后給出了一個(gè)在網(wǎng)易公開(kāi)課使用延遲隊(duì)列的實(shí)踐。

1、有效期：限時(shí)活動(dòng)、拼團(tuán)。。。

2、超時(shí)處理：取消超時(shí)未支付訂單、超時(shí)自動(dòng)確認(rèn)收貨。。。

4、重試：網(wǎng)絡(luò)異常重試、打車(chē)派單、依賴條件未滿足重試。。。

5、定時(shí)任務(wù)：智能設(shè)備定時(shí)啟動(dòng)。。。

1、RabbitMQ

1）簡(jiǎn)介：基于AMQP協(xié)議，使用Erlang編寫(xiě)，實(shí)現(xiàn)了一個(gè)Broker框架

a、Broker：接收和分發(fā)消息的代理服務(wù)器

b、Virtual Host：虛擬主機(jī)之間相互隔離，可理解為一個(gè)虛擬主機(jī)對(duì)應(yīng)一個(gè)消息服務(wù)

c、Exchange：交換機(jī)，消息發(fā)送到指定虛擬機(jī)的交換機(jī)上

d、Binding：交換機(jī)與隊(duì)列綁定，并通過(guò)路由策略和routingKey將消息投遞到一個(gè)或多個(gè)隊(duì)列中

e、Queue：存放消息的隊(duì)列，F(xiàn)IFO，可持久化

f、Channel：信道，消費(fèi)者通過(guò)信道消費(fèi)消息，一個(gè)TCP連接上可同時(shí)創(chuàng)建成百上千個(gè)信道，作為消息隔離

2）延遲隊(duì)列實(shí)現(xiàn)：RabbitMQ的延遲隊(duì)列基于消息的存活時(shí)間TTL（Time To Live）和死信交換機(jī)DLE（Dead Letter Exchanges）實(shí)現(xiàn)

a、TTL：RabbitMQ支持對(duì)隊(duì)列和消息各自設(shè)置存活時(shí)間，取二者中較小的值，即隊(duì)列無(wú)消費(fèi)者連接或消息在隊(duì)列中一直未被消費(fèi)的過(guò)期時(shí)間

b、DLE：過(guò)期的消息通過(guò)綁定的死信交換機(jī)，路由到指定的死信隊(duì)列，消費(fèi)者實(shí)際上消費(fèi)的是死信隊(duì)列上的消息

3）缺點(diǎn)：

a、配置麻煩，額外增加一個(gè)死信交換機(jī)和一個(gè)死信隊(duì)列的配置

b、脆弱性，配置錯(cuò)誤或者生產(chǎn)者消費(fèi)者連接的隊(duì)列錯(cuò)誤都有可能造成延遲失效

2、RocketMQ

1）簡(jiǎn)介：來(lái)源于阿里，目前為Apache頂級(jí)開(kāi)源項(xiàng)目，使用Java編寫(xiě)，基于長(zhǎng)輪詢的拉取方式，支持事務(wù)消息，并解決了順序消息和海量堆積的問(wèn)題

a、Broker：存放Topic并根據(jù)讀取Producer的提交日志，將邏輯上的一個(gè)Topic分多個(gè)Queue存儲(chǔ)，每個(gè)Queue上存儲(chǔ)消息在提交日志上的位置

b、Name Server：無(wú)狀態(tài)的節(jié)點(diǎn)，維護(hù)Topic與Broker的對(duì)應(yīng)關(guān)系以及Broker的主從關(guān)系

2）延遲隊(duì)列實(shí)現(xiàn)：RocketMQ發(fā)送延時(shí)消息時(shí)先把消息按照延遲時(shí)間段發(fā)送到指定的隊(duì)列中(rocketmq把每種延遲時(shí)間段的消息都存放到同一個(gè)隊(duì)列中)，然后通過(guò)一個(gè)定時(shí)器進(jìn)行輪訓(xùn)這些隊(duì)列，查看消息是否到期，如果到期就把這個(gè)消息發(fā)送到指定topic的隊(duì)列中

3）缺點(diǎn)：延遲時(shí)間粒度受限制（1s/5s/10s/30s/1m/2m/3m/4m/5m/6m/7m/8m/9m/10m/20m/30m/1h/2h）

3、Kafka

1）簡(jiǎn)介：來(lái)源于Linkedin，目前為Apache頂級(jí)開(kāi)源項(xiàng)目，使用Scala和Java編寫(xiě)，基于zookeeper協(xié)調(diào)的分布式、流處理的日志系統(tǒng)，升級(jí)版為Jafka

2）延遲隊(duì)列實(shí)現(xiàn)：Kafka支持延時(shí)生產(chǎn)、延時(shí)拉取、延時(shí)刪除等，其基于時(shí)間輪和JDK的DelayQueue實(shí)現(xiàn)

a、時(shí)間輪(TimingWheel)：是一個(gè)存儲(chǔ)定時(shí)任務(wù)的環(huán)形隊(duì)列，底層采用數(shù)組實(shí)現(xiàn)，數(shù)組中的每個(gè)元素可以存放一個(gè)定時(shí)任務(wù)列表

b、定時(shí)任務(wù)列表(TimerTaskList)：是一個(gè)環(huán)形的雙向鏈表，鏈表中的每一項(xiàng)表示的都是定時(shí)任務(wù)項(xiàng)

c、定時(shí)任務(wù)項(xiàng)(TimerTaskEntry)：封裝了真正的定時(shí)任務(wù)TimerTask

d、層級(jí)時(shí)間輪：當(dāng)任務(wù)的到期時(shí)間超過(guò)了當(dāng)前時(shí)間輪所表示的時(shí)間范圍時(shí)，就會(huì)嘗試添加到上層時(shí)間輪中，類(lèi)似于鐘表就是一個(gè)三級(jí)時(shí)間輪

e、JDK DelayQueue：存儲(chǔ)TimerTaskList，并根據(jù)其expiration來(lái)推進(jìn)時(shí)間輪的時(shí)間，每推進(jìn)一次除執(zhí)行相應(yīng)任務(wù)列表外，層級(jí)時(shí)間輪也會(huì)進(jìn)行相應(yīng)調(diào)整

3）缺點(diǎn)：

a、延遲精度取決于時(shí)間格設(shè)置

b、延遲任務(wù)除由超時(shí)觸發(fā)還可能被外部事件觸發(fā)而執(zhí)行

4、ActiveMQ

1）簡(jiǎn)介：基于JMS協(xié)議，Java編寫(xiě)的Apache頂級(jí)開(kāi)源項(xiàng)目，支持點(diǎn)對(duì)點(diǎn)和發(fā)布訂閱兩種模式。

a、點(diǎn)對(duì)點(diǎn)（point-to-point）：消息發(fā)送到指定的隊(duì)列，每條消息只有一個(gè)消費(fèi)者能夠消費(fèi)，基于拉模型

b、發(fā)布訂閱（publish/subscribe）：消息發(fā)送到主題Topic上，每條消息會(huì)被訂閱該Topic的所有消費(fèi)者各自消費(fèi)，基于推模型

2）延遲隊(duì)列實(shí)現(xiàn)：需要延遲的消息會(huì)先存儲(chǔ)在JobStore中，通過(guò)異步線程任務(wù)JobScheduler將到達(dá)投遞時(shí)間的消息投遞到相應(yīng)隊(duì)列上

a、Broker Filter：Broker中定義了一系列BrokerFilter的子類(lèi)構(gòu)成攔截器鏈，按順序?qū)ο⑦M(jìn)行相應(yīng)處理

b、ScheduleBroker：當(dāng)消息中指定了延遲相關(guān)屬性，并且jobId為空時(shí)，會(huì)生成調(diào)度任務(wù)存儲(chǔ)到JobStore中，此時(shí)消息不會(huì)進(jìn)入到隊(duì)列

c、JobStore：基于BTree存儲(chǔ)，key為任務(wù)執(zhí)行的時(shí)間戳，value為該時(shí)間戳下需要執(zhí)行的任務(wù)列表

d、JobScheduler：取JobStore中最小的key執(zhí)行（調(diào)度時(shí)間最早的），執(zhí)行時(shí)間=當(dāng)前時(shí)間，將該任務(wù)列表依次投遞到所屬的隊(duì)列，對(duì)于需要重復(fù)投遞和投遞失敗的會(huì)再次存入JobStore中。

注： 此處JobScheduler的執(zhí)行時(shí)間間隔可動(dòng)態(tài)變化，默認(rèn)0.5s，有新任務(wù)時(shí)會(huì)立即執(zhí)行（Object-notifyAll()）并設(shè)置時(shí)間間隔為0.1s，沒(méi)有新任務(wù)后，下次執(zhí)行時(shí)間為最近任務(wù)的調(diào)度執(zhí)行時(shí)間。

3）缺點(diǎn)：投遞到隊(duì)列失敗，將消息重新存入JobStore，消息調(diào)度執(zhí)行時(shí)間=系統(tǒng)當(dāng)前時(shí)間+延遲時(shí)間，會(huì)導(dǎo)致消息被真實(shí)投遞的時(shí)間可能為設(shè)置的延遲時(shí)間的整數(shù)倍

5、Redis

1）簡(jiǎn)介：基于Key-Value的NoSQL數(shù)據(jù)庫(kù)，由于其極高的性能常被當(dāng)作緩存來(lái)使用，其數(shù)據(jù)結(jié)構(gòu)支持：字符串、哈希、列表、集合、有序集合

2）延遲隊(duì)列實(shí)現(xiàn)：Redis的延遲隊(duì)列基于有序集合，score為執(zhí)行時(shí)間戳，value為任務(wù)實(shí)體或任務(wù)實(shí)體引用

3）缺點(diǎn)：

a、實(shí)現(xiàn)復(fù)雜，本身不支持

b、完全基于內(nèi)存，延遲時(shí)間長(zhǎng)浪費(fèi)內(nèi)存資源

6、消息隊(duì)列對(duì)比

1、公開(kāi)課延遲隊(duì)列技術(shù)選型

1）業(yè)務(wù)場(chǎng)景：關(guān)閉超時(shí)未支付訂單、限時(shí)優(yōu)惠活動(dòng)、拼團(tuán)

2）性能要求：訂單、活動(dòng)、拼團(tuán) 數(shù)據(jù)量可控，上述MQ均能滿足要求

3）可靠性：使用ActiveMQ、RabbitMQ、RocketMQ作為延遲隊(duì)列更普遍

4）可用性：ActiveMQ、RocketMQ自身支持延遲隊(duì)列功能，且目前公開(kāi)課業(yè)務(wù)中使用的中間件為ActiveMQ和Kafka

5）延遲時(shí)間靈活：活動(dòng)的開(kāi)始和結(jié)束時(shí)間比較靈活，而RocketMQ時(shí)間粒度較粗，Kafka會(huì)依賴時(shí)間格有精度缺失

結(jié)論： 最終選擇ActiveMQ來(lái)作為延遲隊(duì)列

2、業(yè)務(wù)場(chǎng)景：關(guān)閉未支付訂單

1）關(guān)閉微信未支付訂單

2）關(guān)閉IOS未支付訂單

3、ActiveMQ使用方式

1）activemq.xml中支持調(diào)度任務(wù)

2）發(fā)送消息時(shí)，設(shè)置message的延遲屬性

其中：

a、延遲處理

AMQ_SCHEDULED_DELAY：設(shè)置多長(zhǎng)時(shí)間后，投遞給消費(fèi)者（毫秒）

b、重復(fù)投遞

AMQ_SCHEDULED_PERIOD：重復(fù)投遞時(shí)間間隔（毫秒）

AMQ_SCHEDULED_REPEAT：重復(fù)投遞次數(shù)

c、指定調(diào)度計(jì)劃

AMQ_SCHEDULED_CRON：corn正則表達(dá)式

4、公開(kāi)課使用中進(jìn)行的優(yōu)化

1）可靠性：針對(duì)實(shí)際投遞時(shí)間可能翻倍的問(wèn)題，結(jié)合ActiveMQ的重復(fù)投遞，在消費(fèi)者邏輯中做冪等處理來(lái)保證延遲時(shí)間的準(zhǔn)確性

2）可追溯性：延遲消息及消費(fèi)情況做數(shù)據(jù)庫(kù)冗余存儲(chǔ)

3）易用性：業(yè)務(wù)上定義好延遲枚舉類(lèi)型，直接使用JmsDelayTemplate發(fā)送，無(wú)需關(guān)心數(shù)據(jù)備份和參數(shù)等細(xì)節(jié)

1、無(wú)論是基于死信隊(duì)列還是基于數(shù)據(jù)先存儲(chǔ)后投遞，本質(zhì)上都是將延遲待發(fā)送的消息數(shù)據(jù)與正常訂閱的隊(duì)列分開(kāi)存儲(chǔ)，從而降低耦合度

2、無(wú)論是檢查隊(duì)頭消息TTL還是調(diào)度存儲(chǔ)的延遲數(shù)據(jù)，本質(zhì)上都是通過(guò)定時(shí)任務(wù)來(lái)完成的，但是定時(shí)任務(wù)的觸發(fā)策略以及延遲數(shù)據(jù)的存儲(chǔ)方式?jīng)Q定了不同中間件之間的性能優(yōu)劣

張浩，2018年加入網(wǎng)易傳媒，高級(jí)Java開(kāi)發(fā)工程師，目前在網(wǎng)易公開(kāi)課主要做支付財(cái)務(wù)體系、版本迭代相關(guān)的工作。