優(yōu)酷土豆的Redis服務(wù)平臺化之路

優(yōu)酷土豆的Redis服務(wù)平臺化之路


1

Redis架構(gòu)的方案經(jīng)歷階段

1.1.?客戶端分片

客戶端分片:

優(yōu)點

不依賴于第三方中間件蹋订,實現(xiàn)方法和代碼自己掌控澜驮,可隨時調(diào)整

這種分片機制的性能比代理式更好(少了一個中間分發(fā)環(huán)節(jié))

可控的分發(fā)請求,分發(fā)壓力落在客戶端,無服務(wù)器壓力增加

缺點

不能平滑的水平擴展節(jié)點,擴容/縮容時祈秕,必須手動調(diào)整分片程序

出現(xiàn)故障渺贤,不能自動轉(zhuǎn)移,運維性很差

客戶端得自己維護一套路由算法

升級復(fù)雜

1.2.?Twemproxy

Twemproxy:

優(yōu)點

運維成本低请毛。業(yè)務(wù)方不用關(guān)心后端Redis實例志鞍,跟操作Redis一樣

Proxy 的邏輯和存儲的邏輯是隔離的

缺點

代理層多了一次轉(zhuǎn)發(fā),性能有所損耗

進行擴容/縮容時候方仿,部分?jǐn)?shù)據(jù)可能會失效固棚,需要手動進行遷移,對運維要求較高兼丰,而且難以做到平滑的擴縮容

出現(xiàn)故障玻孟,不能自動轉(zhuǎn)移,運維性很差

升級復(fù)雜

1.3.?Redis Cluster

Redis Cluster:

優(yōu)點

無中心節(jié)點

數(shù)據(jù)按照Slot存儲分布在多個Redis實例上

平滑的進行擴容/縮容節(jié)點

自動故障轉(zhuǎn)移(節(jié)點之間通過Gossip協(xié)議交換狀態(tài)信息,進行投票機制完成Slave到Master角色的提升)

降低運維成本鳍征,提高了系統(tǒng)的可擴展性和高可用性

缺點

嚴(yán)重依賴外部Redis-Trib

缺乏監(jiān)控管理

需要依賴Smart Client(連接維護, 緩存路由表, MultiOp和Pipeline支持)

Failover節(jié)點的檢測過慢黍翎,不如“中心節(jié)點ZooKeeper”及時

Gossip消息的開銷

無法根據(jù)統(tǒng)計區(qū)分冷熱數(shù)據(jù)

Slave“冷備”,不能緩解讀壓力

1.4.?Proxy+Redis Cluster

Smart Client vs Proxy:

優(yōu)點

Smart Client:

a.?相比于使用代理艳丛,減少了一層網(wǎng)絡(luò)傳輸?shù)南南坏В瘦^高。

b.?不依賴于第三方中間件氮双,實現(xiàn)方法和代碼自己掌控碰酝,可隨時調(diào)整。

Proxy:

a.?提供一套HTTP Restful接口戴差,隔離底層存儲送爸。對客戶端完全透明,跨語言調(diào)用暖释。

b.?升級維護較為容易袭厂,維護Redis Cluster,只需要平滑升級Proxy球匕。

c.?層次化存儲纹磺,底層存儲做冷熱異構(gòu)存儲。

d.?權(quán)限控制亮曹,Proxy可以通過秘鑰控制白名單橄杨,把一些不合法的請求都過濾掉。并且也可以控制用戶請求的超大Value進行控制照卦,和過濾式矫。

e.?安全性,可以屏蔽掉一些危險命令窄瘟,比如Keys衷佃、Save、Flush All等蹄葱。

f.?容量控制氏义,根據(jù)不同用戶容量申請進行容量限制。

g.?資源邏輯隔離图云,根據(jù)不同用戶的Key加上前綴惯悠,來進行資源隔離。

h.?監(jiān)控埋點竣况,對于不同的接口進行埋點監(jiān)控等信息克婶。

缺點

Smart Client:

a.?客戶端的不成熟,影響應(yīng)用的穩(wěn)定性丹泉,提高開發(fā)難度情萤。

b.?MultiOp和Pipeline支持有限。

c.?連接維護摹恨,Smart客戶端對連接到集群中每個結(jié)點Socket的維護筋岛。

Proxy:

a. ?代理層多了一次轉(zhuǎn)發(fā),性能有所損耗晒哄。

b.進行擴容/縮容時候?qū)\維要求較高睁宰,而且難以做到平滑的擴縮容。

2

為什么選擇Nginx開發(fā)Proxy

1.單Master多Work模式寝凌,每個Work跟Redis一樣都是單進程單線程模式柒傻,并且都是基

于Epoll事件驅(qū)動的模式。

2.Nginx采用了異步非阻塞的方式來處理請求较木,高效的異步框架红符。

3.內(nèi)存占用少,有自己的一套內(nèi)存池管理方式,伐债。將大量小內(nèi)存的申請聚集到一塊预侯,能夠比Malloc 更快。減少內(nèi)存碎片泳赋,防止內(nèi)存泄漏雌桑。減少內(nèi)存管理復(fù)雜度。

4. ?為了提高Nginx的訪問速度祖今,Nginx使用了自己的一套連接池校坑。

5. ?最重要的是支持自定義模塊開發(fā)。

6. ?業(yè)界內(nèi)千诬,對于Nginx耍目,Redis的口碑可稱得上兩大神器。性能也就不用說了徐绑。

3

Proxy+Redis Cluster介紹

3.1??Proxy+Redis Cluster架構(gòu)方案介紹

1.?用戶在ACL平臺申請集群資源邪驮,如果申請成功返回秘鑰信息。

2.?用戶請求接口必須包含申請的秘鑰信息傲茄,請求至LVS服務(wù)器毅访。

3.?LVS根據(jù)負(fù)載均衡策略將請求轉(zhuǎn)發(fā)至Nginx Proxy沮榜。

4.?Nginx Proxy首先會獲取秘鑰信息,然后根據(jù)秘鑰信息去ACL服務(wù)上獲取集群的種子信息喻粹。(種子信息是集群內(nèi)任意幾臺IP:PORT節(jié)點)

然后把秘鑰信息和對應(yīng)的集群種子信息緩存起來蟆融。并且第一次訪問會根據(jù)種子IP:PORT獲取集群Slot對應(yīng)節(jié)點的Mapping路由信息,進行緩存起來守呜。最后根據(jù)Key計算SlotId型酥,從緩存路由找到節(jié)點信息。

5.?把相應(yīng)的K/V信息發(fā)送到對應(yīng)的Redis節(jié)點上查乒。

6.?Nginx?Proxy定時(60s)上報請求接口埋點的QPS,RT,Err等信息到Open-Falcon平臺弥喉。

7.?Redis?Cluster定時(60s)上報集群相關(guān)指標(biāo)的信息到Open-Falcon平臺。

3.2??Nginx Proxy功能介紹

目前支持的功能:

HTTP Restful接口:

解析用戶Post過來的數(shù)據(jù)玛迄, 并且構(gòu)建Redis協(xié)議由境。客戶端不需要開發(fā)Smart Client,?對客戶端完全透明憔晒、跨語言調(diào)用

權(quán)限控制:

根據(jù)用戶Post數(shù)據(jù)獲取AppKey,Uri, 然后去ACL Service服務(wù)里面進行認(rèn)證藻肄。如果認(rèn)證通過,會給用戶返回相應(yīng)的集群種子IP拒担,以及相應(yīng)的過期時間限制等信息

限制數(shù)據(jù)大朽谕汀:

獲取用戶Post過來的數(shù)據(jù),對Key从撼,Value長度進行限制州弟,避免產(chǎn)生超大的Key,Value,打滿網(wǎng)卡低零、阻塞Proxy

數(shù)據(jù)壓縮/解壓:

如果是寫請求婆翔,對Value進行壓縮(Snappy),然后在把壓縮后的數(shù)據(jù)存儲到Redis Cluster掏婶。

如果是讀請求啃奴,把Value從Redis Cluster讀出來,然后對Value進行解壓雄妥,最后響應(yīng)給用戶最蕾。

緩存路由信息:

維護路由信息,Slot對應(yīng)的節(jié)點的Mapping信息

結(jié)果聚合:

MultiOp支持

批量指令支持(Pipeline/Redis+Lua+EVALSHA進行批量指令執(zhí)行)

資源邏輯隔離:

根據(jù)用戶Post數(shù)據(jù)獲取該用戶申請的NameSpace老厌,然后以NameSpace作為該用戶請求Key的前綴瘟则,從而達(dá)到不同用戶的不同NameSpace,進行邏輯資源隔離

重試策略:

針對后端Redis節(jié)點出現(xiàn)Moved,Ask,Err,TimeOut等進行重試枝秤,重試次數(shù)可配置

連接池:

維護用戶請求的長連接醋拧,維護后端服務(wù)器的長連接

配額管理:

根據(jù)用戶的前綴(NameSpace), 定時的去抓取RANDOMKEY,根據(jù)一定的比率,估算出不同用戶的容量大小值丹壕,然后在對用戶的配額進行限制管理

過載保護:

通過在Nginx Proxy Limit模塊進行限速庆械,超過集群的承載能力,進行過載保護雀费。從而保證部分用戶可用干奢,不至于壓垮服務(wù)器

監(jiān)控管理:

Nginx Proxy接入了Open-Falcon對系統(tǒng)級別痊焊,應(yīng)用級別盏袄,業(yè)務(wù)級別進行監(jiān)控和告警

例如:?接口的QPS,RT,ERR等進行采集監(jiān)控,并且展示到DashBoard上

告警閾值的設(shè)置非常靈活薄啥,配置化

待開發(fā)的功能列表:

層次化存儲:

利用Nginx Proxy共享內(nèi)存定制化開發(fā)一套LRU本地緩存實現(xiàn)辕羽,從而減少網(wǎng)絡(luò)請求

冷數(shù)據(jù)Swap到慢存儲,從而實現(xiàn)冷熱異構(gòu)存儲

主動Failover節(jié)點:

由于Redis Cluster是通過Gossip通信, 超過半數(shù)以上Master節(jié)點通信(cluster-node-timeout)認(rèn)為當(dāng)前Master節(jié)點宕機垄惧,才真的確認(rèn)該節(jié)點宕機刁愿。判斷節(jié)點宕機時間過長,在Proxy層加入Raft算法到逊,加快失效節(jié)點判定铣口,主動Failover

3.3??Nginx Proxy性能優(yōu)化

3.3.1??批量接口優(yōu)化方案

1. 子請求變?yōu)閰f(xié)程

案例:

用戶需求調(diào)用批量接口mget(50Key)要求性能高,吞吐高觉壶,響應(yīng)快脑题。

問題:

由于最早用的Nginx Subrequest來做批量接口請求的處理,性能一直不高铜靶,CPU利用率也不高叔遂,QPS提不起來。通過火焰圖觀察分析子請求開銷比較大争剿。

解決方案:

子請求效率較低已艰,因為它需要重新從Server Rewrite開始走一遍Request處理的PHASE。并且子請求共享父請求的內(nèi)存池蚕苇,子請求同時并發(fā)度過大哩掺,導(dǎo)致內(nèi)存較高。

協(xié)程輕量級的線程涩笤,占用內(nèi)存少嚼吞。經(jīng)過調(diào)研和測試,單機一兩百萬個協(xié)程是沒有問題的辆它,

并且性能也很高誊薄。

優(yōu)化前:

a)?用戶請求mget(k1,k2)到Proxy

b)?Proxy根據(jù)k1,k2分別發(fā)起子請求subrequest1,subrequest2

c)?子請求根據(jù)key計算slotid,然后去緩存路由表查找節(jié)點

d)?子請求請求Redis Cluster的相關(guān)節(jié)點锰茉,然后響應(yīng)返回給Proxy

e)?Proxy會合并所有的子請求返回的結(jié)果呢蔫,然后進行解析包裝返回給用戶

優(yōu)化后:

a)?用戶請求mget(k1,k2)到Proxy

b)?Proxy根據(jù)k1,k2分別計算slotid, 然后去緩存路由表查找節(jié)點

c)?Proxy發(fā)起多個協(xié)程coroutine1,?coroutine2并發(fā)的請求Redis Cluster的相關(guān)節(jié)點

d)?Proxy會合并多個協(xié)程返回的結(jié)果,然后進行解析包裝返回給用戶

2. 合并相同槽,批量執(zhí)行指令片吊,減少網(wǎng)絡(luò)開銷

案例:

用戶需求調(diào)用批量接口mget(50key)要求性能高绽昏,吞吐高,響應(yīng)快俏脊。

問題:

經(jīng)過上面協(xié)程的方式進行優(yōu)化后全谤,發(fā)現(xiàn)批量接口性能還是提升不夠高。通過火焰圖觀察分析網(wǎng)絡(luò)開銷比較大爷贫。

解決方案:

因為在Redis Cluster中认然,批量執(zhí)行的key必須在同一個slotid。所以漫萄,我們可以合并相同slotid的key做為一次請求卷员。然后利用Pipeline/Lua+EVALSHA批量執(zhí)行命令來減少網(wǎng)絡(luò)開銷,提高性能腾务。

優(yōu)化前:

a)?用戶請求mget(k1,k2,k3,k4) 到Proxy毕骡。

b)?Proxy會解析請求串,然后計算k1,k2,k3,k4所對應(yīng)的slotid岩瘦。

c)?Proxy會根據(jù)slotid去路由緩存中找到后端服務(wù)器的節(jié)點未巫,并發(fā)的發(fā)起多個請求到后端服務(wù)器。

d)?后端服務(wù)器返回結(jié)果給Proxy,然后Proxy進行解析獲取key對應(yīng)的value启昧。

e)?Proxy把key,value對應(yīng)數(shù)據(jù)包裝返回給用戶叙凡。

優(yōu)化后:

a)?用戶請求mget(k1,k2,k3,k4) 到Proxy。

b)?Proxy會解析請求串箫津,然后計算k1,k2,k3,k4所對應(yīng)的slotid狭姨,然后把相同的slotid進行合并為一次Pipeline請求。

c)?Proxy會根據(jù)slotid去路由緩存中找到后端服務(wù)器的節(jié)點苏遥,并發(fā)的發(fā)起多個請求到后端服務(wù)器饼拍。

d)?后端服務(wù)器返回結(jié)果給Proxy,然后Proxy進行解析獲取key對應(yīng)的value。

e)?Proxy把key,value對應(yīng)數(shù)據(jù)包裝返回給用戶田炭。

3.?對后端并發(fā)度的控制

案例:

當(dāng)用戶調(diào)用批量接口請求mset师抄,如果k數(shù)量幾百個甚至幾千個時,會導(dǎo)致Proxy瞬間同時發(fā)起幾百甚至幾千個協(xié)程同時去訪問后端服務(wù)器Redis Cluster教硫。

問題:

Redis?Cluster同時并發(fā)請求的協(xié)程過多叨吮,會導(dǎo)致連接數(shù)瞬間會很大,甚至超過上限瞬矩,CPU,連接數(shù)忽高忽低茶鉴,對集群造成不穩(wěn)定。

解決方案:

單個批量請求對后端適當(dāng)控制并發(fā)度進行分組并發(fā)請求景用,反向有利于性能提升涵叮,避免超過Redis Cluster連接數(shù),同時Redis Cluster 波動也會小很多,更加的平滑割粮。

優(yōu)化前:

a)?用戶請求批量接口mset(200個key)盾碗。(這里先忽略合并相同槽的邏輯)

b)?Proxy會解析這200個key,會同時發(fā)起200個協(xié)程請求并發(fā)的去請求Redis Cluster舀瓢。

c)?Proxy等待所有協(xié)程請求完成廷雅,然后合并所有協(xié)程請求的響應(yīng)結(jié)果,進行解析京髓,包裝返回給用戶航缀。

優(yōu)化后:

a)?用戶請求批量接口mset(200個key)。 (這里先忽略合并相同槽的邏輯)

b)?Proxy會解析這200個key朵锣,進行分組谬盐。100個key為一組,分批次進行并發(fā)請求诚些。

c)?Proxy先同時發(fā)起第一組100個協(xié)程(coroutine1,?coroutine100)請求并發(fā)的去請求Redis Cluster。

d)?Proxy等待所有協(xié)程請求完成皇型,然后合并所有協(xié)程請求的響應(yīng)結(jié)果诬烹。

e)?Proxy然后同時發(fā)起第二組100個協(xié)程(coroutine101,?coroutine200)請求并發(fā)的去請求Redis Cluster。

f)?Proxy等待所有協(xié)程請求完成弃鸦,然后合并所有協(xié)程請求的響應(yīng)結(jié)果绞吁。

g)?Proxy把所有協(xié)程響應(yīng)的結(jié)果進行解析,包裝唬格,返回給用戶家破。

4.單Work分散到多Work

案例:

當(dāng)用戶調(diào)用批量接口請求mset,如果k數(shù)量幾百個甚至幾千個時购岗,會導(dǎo)致Proxy瞬間同時發(fā)起幾百甚至幾千個協(xié)程同時去訪問后端服務(wù)器Redis Cluster汰聋。

問題:

由于Nginx的框架模型是單進程單線程, 所以Proxy發(fā)起的協(xié)程都會在一個Work上,這樣如果發(fā)起的協(xié)程請求過多就會導(dǎo)致單Work CPU打滿,導(dǎo)致Nginx 的每個Work CPU使用率非常不均喊积,內(nèi)存持續(xù)暴漲的情況烹困。(nginx 的內(nèi)存池只能提前釋放大塊,不會提前釋放小塊)

解決方案:

增加一層緩沖層代理乾吻,把請求的數(shù)據(jù)進行拆分為多份髓梅,然后每份發(fā)起請求,控制并發(fā)度绎签,在轉(zhuǎn)發(fā)給Proxy層枯饿,避免單個較大的批量請求打滿單Work,從而達(dá)到分散多Work诡必,達(dá)到Nginx 多個Wrok CPU使用率均衡奢方。

優(yōu)化前:

a)?用戶請求批量接口mset(200個key)。(這里先忽略合并相同槽的邏輯)

b)?Proxy會解析這200個key,會同時發(fā)起200個協(xié)程請求并發(fā)的去請求Redis Cluster袱巨。

c)?Proxy等待所有協(xié)程請求完成阁谆,然后合并所有協(xié)程請求的響應(yīng)結(jié)果,進行解析愉老,包裝返回給用戶场绿。

優(yōu)化后:

a)?用戶請求批量接口mset(200個key)。(這里先忽略合并相同槽的key的邏輯)

b)?Proxy會解析這200個key嫉入,然后進行拆分分組以此來控制并發(fā)度焰盗。

c)?Proxy會根據(jù)劃分好的組進行一組一組的發(fā)起請求。

d)?Proxy等待所有請求完成咒林,然后合并所有協(xié)程請求的響應(yīng)結(jié)果熬拒,進行解析,包裝返回給用戶垫竞。

總結(jié)澎粟,經(jīng)過上面一系列優(yōu)化,我們可以來看看針對批量接口mset(50個k/v)性能對比圖欢瞪,Nginx?Proxy的響應(yīng)時間比Java版本的響應(yīng)時間快了5倍多活烙。

Java版本:

Nginx版本:

3.3.2??網(wǎng)卡軟中斷優(yōu)化

irqbalance根據(jù)系統(tǒng)中斷負(fù)載的情況,自動遷移中斷保持中斷的平衡遣鼓。但是在實時系統(tǒng)中會導(dǎo)致中斷自動漂移啸盏,對性能造成不穩(wěn)定因素,在高性能的場合建議關(guān)閉骑祟。

1.?首先關(guān)閉網(wǎng)卡軟中斷

service irqbalance stop

service?cpuspeed?stop

2.?查看網(wǎng)卡是隊列

grep eth /proc/interrupts | awk '{print $1, $NF}'

77: eth0

78: eth0-TxRx-0

79: eth0-TxRx-1

80: eth0-TxRx-2

81: eth0-TxRx-3

82: eth0-TxRx-4

83: eth0-TxRx-5

84: eth0-TxRx-6

85: eth0-TxRx-7

3.?綁定網(wǎng)卡軟中斷到CPU0-2號上

(注意這里的echo 是十六進制)

echo "1" > /proc/irq/78/smp_affinity

echo "1" > /proc/irq/79/smp_affinity

echo "2" > /proc/irq/80/smp_affinity

echo "2" > /proc/irq/81/smp_affinity

echo "2" > /proc/irq/82/smp_affinity

echo "4" > /proc/irq/83/smp_affinity

echo "4" > /proc/irq/84/smp_affinity

echo "4" > /proc/irq/85/smp_affinity

3.3.3??綁定進程到指定的CPU

綁定nginx或者redis的pid到cpu3-cpu10上:

taskset -cp 3 1900

taskset -cp 4 1901

taskset -cp 5 1902

taskset -cp 6 1903

taskset -cp 7 1904

taskset -cp 8 1905

taskset -cp 9 1902

taskset -cp 10 1902

或者通過Nginx Proxy配置:

worker_cpu_affinity 綁定CPU親緣性

3.3.4??性能優(yōu)化神器火焰圖

3.4??Redis Cluster運維

3.4.1?運維功能

1. 創(chuàng)建集群

2. 集群擴容/縮容

3.?節(jié)點宕機

4. 集群升級

5. 遷移數(shù)據(jù)

6. 副本遷移

7. 手動failover

8. 手動rebalance

以上相關(guān)運維功能回懦,目前是通過腳本配置化一鍵式操作,依賴于官方的redis-rebalance.rb進行擴展開發(fā)次企。運維非常方便快捷怯晕。

3.5??性能測試報告

3.5.1??測試環(huán)境

軟件:

Jmeter

Nginx Proxy(24核)

Redis集群(4?Master,4 Slave)

測試Key(100000)

硬件:

OS: Centos6.6

CPU:24核

帶寬:千兆

內(nèi)存:62G

測試結(jié)果:

場景:普通K/V

QPS:18W左右

RT: 99都在10ms以內(nèi)

CPU:Nginx Proxy CPU在50%左右

4

監(jiān)控告警

4.1?系統(tǒng)級別

通過Open-Falcon Agent采集服務(wù)器的CPU捅厂、內(nèi)存费坊、網(wǎng)卡流量、網(wǎng)絡(luò)連接殖氏、磁盤等信息蛉谜。

4.2?應(yīng)用級別

通過Open-Falcon?Plugin采集Nginx/Redis進程級別的CPU稚晚,內(nèi)存,Pid等信息型诚。

4.3?業(yè)務(wù)級別

通過在Proxy里面埋點監(jiān)控業(yè)務(wù)接口QPS客燕,RT(50%,99%,999%),請求流量狰贯,錯誤次數(shù)等信息也搓,定時的上報給Open-Falcon赏廓。

通過Open-Falcon?Plugin采集Redis?Cluster集群信息,QPS傍妒,連接數(shù)等相關(guān)指標(biāo)指標(biāo)信息幔摸。

作者介紹:

李航: 5年多互聯(lián)網(wǎng)工作經(jīng)驗,先后在58同城颤练,汽車之家既忆,優(yōu)酷土豆集團工作。目前主要在優(yōu)酷土豆集團任職高級開發(fā)工程師嗦玖,目前主要負(fù)責(zé)大數(shù)據(jù)基礎(chǔ)平臺Redis集群開發(fā)及運維等工作患雇。主要關(guān)注領(lǐng)域Nginx,Redis宇挫,分布式系統(tǒng)苛吱,分布式存儲。如果對redis/hbase/spark/storm/kafka等大數(shù)據(jù)領(lǐng)域有深厚的興趣器瘪,可以發(fā)送簡歷給gaosong@youku.com翠储。

本文來源自“Redis技術(shù)交流群”線上分享。李航ID:Lucien_168娱局。群主ID:gnuhpc彰亥。后期的分享我們會同期進行。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末衰齐,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子继阻,更是在濱河造成了極大的恐慌耻涛,老刑警劉巖,帶你破解...
    沈念sama閱讀 222,681評論 6 517
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件瘟檩,死亡現(xiàn)場離奇詭異抹缕,居然都是意外死亡,警方通過查閱死者的電腦和手機墨辛,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 95,205評論 3 399
  • 文/潘曉璐 我一進店門卓研,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人睹簇,你說我怎么就攤上這事奏赘。” “怎么了太惠?”我有些...
    開封第一講書人閱讀 169,421評論 0 362
  • 文/不壞的土叔 我叫張陵磨淌,是天一觀的道長。 經(jīng)常有香客問我凿渊,道長梁只,這世上最難降的妖魔是什么缚柳? 我笑而不...
    開封第一講書人閱讀 60,114評論 1 300
  • 正文 為了忘掉前任,我火速辦了婚禮搪锣,結(jié)果婚禮上秋忙,老公的妹妹穿的比我還像新娘。我一直安慰自己构舟,他們只是感情好灰追,可當(dāng)我...
    茶點故事閱讀 69,116評論 6 398
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著旁壮,像睡著了一般监嗜。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上抡谐,一...
    開封第一講書人閱讀 52,713評論 1 312
  • 那天裁奇,我揣著相機與錄音,去河邊找鬼麦撵。 笑死刽肠,一個胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的免胃。 我是一名探鬼主播音五,決...
    沈念sama閱讀 41,170評論 3 422
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼羔沙!你這毒婦竟也來了躺涝?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 40,116評論 0 277
  • 序言:老撾萬榮一對情侶失蹤扼雏,失蹤者是張志新(化名)和其女友劉穎坚嗜,沒想到半個月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體诗充,經(jīng)...
    沈念sama閱讀 46,651評論 1 320
  • 正文 獨居荒郊野嶺守林人離奇死亡苍蔬,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 38,714評論 3 342
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了蝴蜓。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片碟绑。...
    茶點故事閱讀 40,865評論 1 353
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖茎匠,靈堂內(nèi)的尸體忽然破棺而出格仲,到底是詐尸還是另有隱情,我是刑警寧澤汽抚,帶...
    沈念sama閱讀 36,527評論 5 351
  • 正文 年R本政府宣布抓狭,位于F島的核電站,受9級特大地震影響造烁,放射性物質(zhì)發(fā)生泄漏否过。R本人自食惡果不足惜午笛,卻給世界環(huán)境...
    茶點故事閱讀 42,211評論 3 336
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望苗桂。 院中可真熱鬧药磺,春花似錦、人聲如沸煤伟。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,699評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽便锨。三九已至围辙,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間放案,已是汗流浹背姚建。 一陣腳步聲響...
    開封第一講書人閱讀 33,814評論 1 274
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留吱殉,地道東北人掸冤。 一個月前我還...
    沈念sama閱讀 49,299評論 3 379
  • 正文 我出身青樓,卻偏偏與公主長得像友雳,于是被迫代替她去往敵國和親稿湿。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 45,870評論 2 361

推薦閱讀更多精彩內(nèi)容

  • 轉(zhuǎn)發(fā):Redis Cluster探索與思考 Redis Cluster的基本原理和架構(gòu) Redis Cluster...
    meng_philip123閱讀 3,588評論 0 14
  • 本文將從Redis的基本特性入手,通過講述Redis的數(shù)據(jù)結(jié)構(gòu)和主要命令對Redis的基本能力進行直觀介紹流礁。之后概...
    kelgon閱讀 61,177評論 23 625
  • 轉(zhuǎn)載地址:http://gnucto.blog.51cto.com/3391516/998509 Redis與Me...
    Ddaidai閱讀 21,453評論 0 82
  • Spring Cloud為開發(fā)人員提供了快速構(gòu)建分布式系統(tǒng)中一些常見模式的工具(例如配置管理策精,服務(wù)發(fā)現(xiàn),斷路器崇棠,智...
    卡卡羅2017閱讀 134,716評論 18 139
  • 不知從什么時候開始,我竟給自己畫了張臉譜丸卷,而且時時改變著枕稀,樂此不疲。慢慢地谜嫉,我發(fā)現(xiàn)萎坷,幾乎所有的人都為自己畫了臉譜,...
    jerrybirdy閱讀 157評論 0 2