建站
咨詢
售后
建站咨詢
新聞中心
如何設(shè)置數(shù)據(jù)庫(kù)緩存
內(nèi)存數(shù)據(jù)庫(kù)有現(xiàn)成的redis，高效存取鍵值對(duì)，鍵設(shè)為你的查詢條件，值設(shè)為你的查詢結(jié)果轉(zhuǎn)為字符串
創(chuàng)新互聯(lián)從2013年創(chuàng)立，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目網(wǎng)站建設(shè)、成都網(wǎng)站制作網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢(mèng)想脫穎而出為使命，1280元宿松做網(wǎng)站,已為上家服務(wù),為宿松各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話:18982081108
查詢時(shí)先從redis取，沒(méi)有再查數(shù)據(jù)庫(kù)，并且設(shè)置redis的過(guò)期時(shí)間，這種方式需要項(xiàng)目對(duì)實(shí)時(shí)性要求不高，這樣你才能用緩存，而且如果你的項(xiàng)目沒(méi)有明顯的熱點(diǎn)，即沒(méi)有某些內(nèi)容確定會(huì)多次被查到，那你緩存就不會(huì)命中，添加緩存反而影響你得速度
redis是一種nosql的內(nèi)存數(shù)據(jù)庫(kù)，感興趣你可以了解一下，優(yōu)點(diǎn)就是性能強(qiáng)勁
數(shù)據(jù)查詢請(qǐng)求多就把結(jié)果緩存下來(lái)，你查數(shù)據(jù)庫(kù)再快也沒(méi)有直接把結(jié)果從內(nèi)存讀出來(lái)快
同樣的sql請(qǐng)求只有第一次查數(shù)據(jù)庫(kù)，之后通通讀內(nèi)存
或者你干脆借助這種思想，創(chuàng)建一個(gè)全局的map對(duì)象，然后查詢條件作key
，結(jié)果作value，就省去了了解redis的過(guò)程，把整個(gè)數(shù)據(jù)庫(kù)裝內(nèi)存不太科學(xué)，你有多少條數(shù)據(jù)啊
nosql數(shù)據(jù)庫(kù)的四種類型
一般將NoSQL數(shù)據(jù)庫(kù)分為四大類：鍵值(Key-Value)存儲(chǔ)數(shù)據(jù)庫(kù)、列存儲(chǔ)數(shù)據(jù)庫(kù)、文檔型數(shù)據(jù)庫(kù)和圖形(Graph)數(shù)據(jù)庫(kù)。它們的數(shù)據(jù)模型、優(yōu)缺點(diǎn)、典型應(yīng)用場(chǎng)景。
鍵值(Key-Value)存儲(chǔ)數(shù)據(jù)庫(kù)Key指向Value的鍵值對(duì)，通常用hash表來(lái)實(shí)現(xiàn)查找速度快數(shù)據(jù)無(wú)結(jié)構(gòu)化(通常只被當(dāng)作字符串或者二進(jìn)制數(shù)據(jù))內(nèi)容緩存，主要用于處理大量數(shù)據(jù)的高訪問(wèn)負(fù)載，也用于一些日志系統(tǒng)等。
列存儲(chǔ)數(shù)據(jù)庫(kù)，以列簇式存儲(chǔ)，將同一列數(shù)據(jù)存在一起查找速度快，可擴(kuò)展性強(qiáng)，更容易進(jìn)行分布式擴(kuò)展功能相對(duì)局限分布式的文件系統(tǒng)。
文檔型數(shù)據(jù)庫(kù)，Key-Value對(duì)應(yīng)的鍵值對(duì)，Value為結(jié)構(gòu)化數(shù)據(jù)，數(shù)據(jù)結(jié)構(gòu)要求不嚴(yán)格，表結(jié)構(gòu)可變(不需要像關(guān)系型數(shù)據(jù)庫(kù)一樣需預(yù)先定義表結(jié)構(gòu))，查詢性能不高，而且缺乏統(tǒng)一的查詢語(yǔ)法，Web應(yīng)用。
圖形(Graph)數(shù)據(jù)庫(kù)，圖結(jié)構(gòu)，利用圖結(jié)構(gòu)相關(guān)算法(如最短路徑尋址，N度關(guān)系查找等)，很多時(shí)候需要對(duì)整個(gè)圖做計(jì)算才能得出需要的信息，而且這種結(jié)構(gòu)不太好做分布式的集群方案，社交網(wǎng)絡(luò)，推薦系統(tǒng)等。
redis一般用來(lái)干嘛
redis是一個(gè)單線程的NoSQL數(shù)據(jù)庫(kù)，主要用來(lái)做數(shù)據(jù)緩存，一般大型網(wǎng)站的應(yīng)用和數(shù)據(jù)庫(kù)之間的那一層就是Redis。比如京東商城的頁(yè)面查找功能，用戶接觸到的查詢的第一層就是Redis數(shù)據(jù)緩存層，緩存中找不到的數(shù)據(jù)，再進(jìn)入數(shù)據(jù)庫(kù)查詢。Redis中緩存熱點(diǎn)數(shù)據(jù)，能夠保護(hù)數(shù)據(jù)庫(kù)，提高查詢效率。
NoSQL，泛指非關(guān)系型的數(shù)據(jù)庫(kù)。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起，傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)在處理web2.0網(wǎng)站，特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動(dòng)態(tài)網(wǎng)站已經(jīng)顯得力不從心，出現(xiàn)了很多難以克服的問(wèn)題，而非關(guān)系型的數(shù)據(jù)庫(kù)則由于其本身的特點(diǎn)得到了非常迅速的發(fā)展。NoSQL數(shù)據(jù)庫(kù)的產(chǎn)生就是為了解決大規(guī)模數(shù)據(jù)集合多重?cái)?shù)據(jù)種類帶來(lái)的挑戰(zhàn)，特別是大數(shù)據(jù)應(yīng)用難題。
redis是什么類型的nosql數(shù)據(jù)庫(kù)
內(nèi)存數(shù)據(jù)庫(kù)，也叫緩存，可以存儲(chǔ)訪問(wèn)頻次很高的數(shù)據(jù)
redis是一個(gè)nosql(not only sql不僅僅只有sql)數(shù)據(jù)庫(kù)，翻譯成中文叫做非關(guān)系型型數(shù)據(jù)庫(kù)
網(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ò)異常重試、打車派單、依賴條件未滿足重試。。。
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í)間輪中，類似于鐘表就是一個(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的子類構(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ù)上定義好延遲枚舉類型，直接使用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)的工作。
nosql數(shù)據(jù)庫(kù)有哪些？？？
NoSQL(NoSQL
=
Not
Only
SQL
)，意即“不僅僅是SQL”，是一項(xiàng)全新的數(shù)據(jù)庫(kù)革命性運(yùn)動(dòng)，早期就有人提出，發(fā)展至2009年趨勢(shì)越發(fā)高漲。NoSQL的擁護(hù)者們提倡運(yùn)用非關(guān)系型的數(shù)據(jù)存儲(chǔ)，相對(duì)于鋪天蓋地的關(guān)系型數(shù)據(jù)庫(kù)運(yùn)用，這一概念無(wú)疑是一種全新的思維的注入。
隨著大數(shù)據(jù)的不斷發(fā)展，非關(guān)系型的數(shù)據(jù)庫(kù)現(xiàn)在成了一個(gè)極其熱門的新領(lǐng)域，非關(guān)系數(shù)據(jù)庫(kù)產(chǎn)品的發(fā)展非常迅速。現(xiàn)今的計(jì)算機(jī)體系結(jié)構(gòu)在數(shù)據(jù)存儲(chǔ)方面要有龐大的水平擴(kuò)展性，而NoSQL也正是致力于改變這一現(xiàn)狀。目前Google的
BigTable和Amazon
的Dynamo使用的就是NoSQL型數(shù)據(jù)庫(kù)，本文介紹了10種出色的NoSQL數(shù)據(jù)庫(kù)。
雖然NoSQL流行語(yǔ)火起來(lái)才短短一年的時(shí)間，但是不可否認(rèn)，現(xiàn)在已經(jīng)開(kāi)始了第二代運(yùn)動(dòng)。盡管早期的堆棧代碼只能算是一種實(shí)驗(yàn)，然而現(xiàn)在的系統(tǒng)已經(jīng)更加的成熟、穩(wěn)定。不過(guò)現(xiàn)在也面臨著一個(gè)嚴(yán)酷的事實(shí)：技術(shù)越來(lái)越成熟——以至于原來(lái)很好的NoSQL數(shù)據(jù)存儲(chǔ)不得不進(jìn)行重寫(xiě)，也有少數(shù)人認(rèn)為這就是所謂的2.0版本。這里列出一些比較知名的NoSQL工具，可以為大數(shù)據(jù)建立快速、可擴(kuò)展的存儲(chǔ)庫(kù)。
給一個(gè)地址吧
當(dāng)前文章：nosql數(shù)據(jù)庫(kù)緩存,mysql 數(shù)據(jù)庫(kù)緩存
當(dāng)前地址：http://www.dlmjj.cn/article/dsihjdh.html
