chinese直男口爆体育生外卖, 99久久er热在这里只有精品99, 又色又爽又黄18禁美女裸身无遮挡, gogogo高清免费观看日本电视,私密按摩师高清版在线,人妻视频毛茸茸,91论坛 兴趣闲谈,欧美 亚洲 精品 8区,国产精品久久久久精品免费

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

Redis搶紅包項目

數(shù)據(jù)分析與開發(fā) ? 來源:數(shù)據(jù)分析與開發(fā) ? 作者:數(shù)據(jù)分析與開發(fā) ? 2020-09-24 15:09 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

業(yè)務(wù)流程分析

功能拆解


新建紅包

在 DB、Redis 分別新增一條記錄

搶紅包(并發(fā))

「使用技術(shù)」

Redis 中數(shù)據(jù)類型的 String 特性的原子遞減(DECR key)和減少指定值(DECRBY key decrement)

「業(yè)務(wù)」

請求 Redis ,當(dāng)剩余紅包個數(shù)大于 0,紅包個數(shù)原子遞減,隨機獲取紅包

計算金額,當(dāng)最后一個紅包時,最后一個紅包金額=總金額-總已搶紅包金額

更新數(shù)據(jù)庫

「查詢紅包記錄」

查詢 DB 即可

數(shù)據(jù)庫設(shè)計

紅包流水表

CREATE TABLE `red_packet_info` ( `id` int(11) NOT NULL AUTO_INCREMENT, `red_packet_id` bigint(11) NOT NULL DEFAULT 0 COMMENT '紅包id,采? timestamp+5位隨機數(shù)', `total_amount` int(11) NOT NULL DEFAULT 0 COMMENT '紅包總?額,單位分', `total_packet` int(11) NOT NULL DEFAULT 0 COMMENT '紅包總個數(shù)', `remaining_amount` int(11) NOT NULL DEFAULT 0 COMMENT '剩余紅包?額,單位 分', `remaining_packet` int(11) NOT NULL DEFAULT 0 COMMENT '剩余紅包個數(shù)', `uid` int(20) NOT NULL DEFAULT 0 COMMENT '新建紅包?戶的?戶標(biāo)識', `create_time` timestamp COMMENT '創(chuàng)建時間', `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新時間', PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='紅包信息 表,新建?個紅包插??條記錄';

紅包記錄表

CREATE TABLE `red_packet_record` ( `id` int(11) NOT NULL AUTO_INCREMENT, `amount` int(11) NOT NULL DEFAULT '0' COMMENT '搶到紅包的?額', `nick_name` varchar(32) NOT NULL DEFAULT '0' COMMENT '搶到紅包的?戶的?戶 名', `img_url` varchar(255) NOT NULL DEFAULT '0' COMMENT '搶到紅包的?戶的頭像', `uid` int(20) NOT NULL DEFAULT '0' COMMENT '搶到紅包?戶的?戶標(biāo)識', `red_packet_id` bigint(11) NOT NULL DEFAULT '0' COMMENT '紅包id,采? timestamp+5位隨機數(shù)', `create_time` timestamp COMMENT '創(chuàng)建時間', `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新時間', PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='搶紅包記 錄表,搶?個紅包插??條記錄';

發(fā)紅包 API

發(fā)紅包接口開發(fā)

新增一條紅包記錄

往 mysql 里面添加一條紅包記錄

往 redis 里面添加一條紅包數(shù)量記錄

往redis里面添加一條紅包金額記錄

?

往db中就單純存入一條記錄,Service層和Mapper層,就簡單的一條sql語句,主要是提供思路,下面會附案例源碼,不要慌

?

搶紅包 API

搶紅包功能屬于原子減操作

當(dāng)大小小于 0 時原子減失敗

當(dāng)紅包個數(shù)為0時,后面進來的用戶全部搶紅包失敗,并不會進入拆紅包環(huán)節(jié)

搶紅包功能設(shè)計

將紅包ID的請求放入請求隊列中,如果發(fā)現(xiàn)超過紅包的個數(shù),直接返回

注意事項

搶到紅包不一定能拆成功

搶紅包算法拆解

img

通過上圖算法得出,靠前面的人,手氣最佳幾率小,手氣最佳,往往在后面

發(fā) 100 元,共 10 個紅包,那么平均值是 10 元一個,那么發(fā)出來的紅包金額在 0.01~20 元之間波動

當(dāng)前面 4 個紅包總共被領(lǐng)了 30 元時,剩下 70 元,總共 6 個紅包,那么這 6 個紅包的金額在 0.01~23.3 元之間波動

搶紅包接口開發(fā)

「測試」

「發(fā)紅包」

模擬高并發(fā)搶紅包(Jmeter壓測工具)

因為我發(fā)了 10 個紅包,金額是 20000,使用壓測工具,模擬50個請求,只允許前10個請求能搶到紅包,并且金額等于20000。

布隆過濾器

介紹

布隆過濾器是1970年由布隆提出的。它實際上是一個很長的二進制向量和一系列隨機映射函數(shù)。布隆過濾器可以用于檢索一個元素是否在一個集合中。它的優(yōu)點是空間效率和查詢時間都遠遠超過一般的算法,缺點是有一定的誤識別率和刪除困難。

優(yōu)點

相比于其他的數(shù)據(jù)結(jié)構(gòu),布隆過濾器在空間和時間方面都有巨大的優(yōu)勢。布隆過濾器存儲空間和插入/查詢時間都是常數(shù)。另外三列函數(shù)相互之間沒有關(guān)系,方便由硬件并行實現(xiàn)。布隆過濾器不需要存儲元素本身,在某些對保密要求非常嚴(yán)格的場合有優(yōu)勢。

缺點

但是布隆過濾器的缺點和有點一樣明顯。誤算率是其中之一。隨著存入的元素數(shù)量增加,誤算率隨之增加。但是如果元素數(shù)量太少,則使用散列表足矣。

布隆過濾器有什么用

黑客流量攻擊:故意訪問不存在的數(shù)據(jù),導(dǎo)致查程序不斷訪問DB的數(shù)據(jù)

黑客安全阻截:當(dāng)黑客訪問不存在的緩存時迅速返回避免緩存及DB掛掉

網(wǎng)頁爬蟲對 URL 的去重,避免爬取相同的URL地址

反垃圾郵件,從數(shù)十億個垃圾郵件列表中判斷某郵件是否垃圾郵件(同理,垃圾短信)

緩存擊穿,將已存在的緩存放到布隆中,當(dāng)黑客訪問不存在的緩存時迅速返回避免緩存及 DB 掛掉

布隆過濾器實現(xiàn)會員轉(zhuǎn)盤抽獎

需求

一個抽獎程序,只針對會員用戶有效

通過google布隆過濾器存儲會員數(shù)據(jù)

程序啟動時將數(shù)據(jù)放入內(nèi)存中

google自動創(chuàng)建布隆過濾器

用戶ID進來之后判斷是否是會員

代碼實現(xiàn)

引入依賴

com.google.guava guava 29.0-jre

數(shù)據(jù)庫會員表

CREATE TABLE `sys_user` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `user_name` varchar(11) CHARACTER SET utf8mb4 DEFAULT NULL COMMENT '?戶名', `image` varchar(11) CHARACTER SET utf8mb4 DEFAULT NULL COMMENT '?戶頭像', PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=utf8;

初始化布隆過濾器

dao 層和 dao 映射文件,就單純的一個 sql 查詢,看核心方法,下面會附源碼滴,不要慌好嘛

控制層

測試

缺點

內(nèi)存級別產(chǎn)部

重啟即失效

本地內(nèi)存無法用在分布式場景

不支持大數(shù)據(jù)量存儲

Redis布隆過濾器

優(yōu)點

可擴展性 Bloom 過濾器

不存在重啟即失效或定時任務(wù)維護的成本

缺點

需要網(wǎng)絡(luò)IO,性能比基于內(nèi)存的過濾器低

布隆過濾器安裝

「下載」

github:https://github.com/RedisBloom/RedisBloom

鏈接:https://pan.baidu.com/s/16DlKLm8WGFzGkoPpy8y4Aw密碼:25w1

「編譯」

make

「將 Rebloom 加載到 Redis 中」

先把 Redis 給停掉!?。≡?redis.conf 里面添加一行命令->加載模塊

loadmodule/usr/soft/RedisBloom-2.2.4/redisbloom.so

「測試布隆過濾器」

SpringBoot 整合 Redis 布隆過濾器

編寫兩個lua腳本

添加數(shù)據(jù)到指定名稱的布隆過濾器

從指定名稱的布隆過濾器獲取key是否存在的腳本

localbloomName=KEYS[1] localvalue=KEYS[2] --bloomFilter localresult_1=redis.call('BF.ADD',bloomName,value) returnresult_1

localbloomName=KEYS[1] localvalue=KEYS[2] --bloomFilter localresult_1=redis.call('BF.EXISTS',bloomName,value) returnresult_1

在 RedisService.java 中添加 2 個方法

驗證

秒殺

秒殺業(yè)務(wù)流程圖

數(shù)據(jù)落地存儲方案

通過分布式redis減庫存

DB存最終訂單信息數(shù)據(jù)

API性能調(diào)優(yōu)

性能瓶頸在高并發(fā)秒殺

技術(shù)難題在于超賣問題

實現(xiàn)步驟

提前將秒殺數(shù)據(jù)緩存到 redis

setskuId_start_10_1554045087--秒殺標(biāo)識 setskuId_access_112000--允許搶購數(shù) setskuId_count_10--搶購計數(shù) setskuId_booked_10--真實秒殺數(shù)

秒殺開始前,skuId_start為0,代表活動未開始

當(dāng)skuId_start改為1時,活動開始,開始秒殺叭

當(dāng)接受下單數(shù)達到sku_count*1.2后,繼續(xù)攔截所有請求,商品剩余數(shù)量為0(為啥接受搶購數(shù)為1萬2呢,看業(yè)務(wù)流程圖,涉及到“校驗訂單信息”,一般設(shè)置的值要比總數(shù)多一點,多多少自己定)

利用 Redis 緩存加速增庫存數(shù)

"skuId_booked":10000//從0開始累加,秒殺的個數(shù)只能加到1萬

將用戶訂單數(shù)據(jù)寫入 MQ(異步方式)。

另外一臺服務(wù)器監(jiān)聽 mq,將訂單信息寫入到 DB。

好了,以上就是完整的開發(fā)步驟,下面我們開始編寫代碼

代碼實戰(zhàn)

網(wǎng)關(guān)瀏覽攔截層

1、先判斷秒殺是否已經(jīng)開始

2、利用 Redis 緩存 incr 攔截流量

用 incr 方法原子加

通過原子加帕努單當(dāng)前 skuId_access 是否達到最大值

訂單信息校驗層

1、校驗當(dāng)前用戶是否已經(jīng)買過這個商品

需要存儲用戶的uid

存數(shù)據(jù)庫效率太低

存Redis value方式數(shù)據(jù)太大

存布隆過濾器性能高且數(shù)據(jù)量小(推薦)

2、校驗通過直接返回搶購成功

開發(fā)lua腳本實現(xiàn)庫存扣除

1、庫存扣除成功,獲取當(dāng)前最新庫存

2、如果庫存大于0,即馬上進行庫存扣除,并且訪問搶購成功給用戶

3、考慮原子性問題

保證原子性的方式,采用 lua 腳本

采用lua腳本方式保證原子性帶來缺點,性能有所下降

不保證原子性缺點,放入請求量可能大于預(yù)期

當(dāng)前扣除庫存場景必須保證原子性,否則會導(dǎo)致超賣

4、返回搶購結(jié)果

搶購成功

庫存沒了,搶購失敗

控制層

Service 層

布隆過濾器

初始化redis緩存

setskuId_start_10_1554045087--秒殺標(biāo)識 setskuId_access_112000--允許搶購數(shù) setskuId_count_10--搶購計數(shù) setskuId_booked_10--真實秒殺數(shù)

秒殺驗證

jmeter 配置

壓測秒殺驗證原子性

項目下載

鏈接:https://pan.baidu.com/s/1hZUPRAljkqO05fYluqJBhQ密碼:1iwr

尾聲

演示的時候,我使用的 Redis 單機的,吞吐量不是很大,感興趣的,可以自己搭建個 Redis 主從復(fù)制+哨兵+集群,然后再測試。

最近比較忙,沒時間完善微信搶紅包秒殺的原子性。下面那個完整案例搶庫存的,親自使用 Jmeter 壓測幾次,是原子性的,可以拿來借鑒,感興趣的同學(xué),可以借鑒下面搶庫存的代碼,把微信搶紅包的功能在完善下,我就不修改啦。

原文標(biāo)題:Redis 秒殺實戰(zhàn)

文章出處:【微信公眾號:數(shù)據(jù)分析與開發(fā)】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • C語言
    +關(guān)注

    關(guān)注

    183

    文章

    7646

    瀏覽量

    146096
  • Redis
    +關(guān)注

    關(guān)注

    0

    文章

    394

    瀏覽量

    12248

原文標(biāo)題:Redis 秒殺實戰(zhàn)

文章出處:【微信號:DBDevs,微信公眾號:數(shù)據(jù)分析與開發(fā)】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評論

    相關(guān)推薦
    熱點推薦

    Redis應(yīng)用監(jiān)控指標(biāo)大盤點

    Redis作為高性能內(nèi)存數(shù)據(jù)庫,廣泛應(yīng)用于緩存、會話存儲、消息隊列等場景。對Redis運行狀況的有效監(jiān)控,是保障業(yè)務(wù)穩(wěn)定性的關(guān)鍵。本文的目的是幫助運維工程師建立完整的Redis監(jiān)控知識體系,講解需要監(jiān)控哪些指標(biāo)、如何采集這些指標(biāo)
    的頭像 發(fā)表于 04-09 10:07 ?133次閱讀

    全方位對比:Redis能取代MySQL嗎?看完這篇你就懂了

    Redis能不能取代MySQL?答案很明確:不能取代,但可以互補。
    的頭像 發(fā)表于 04-07 10:50 ?133次閱讀
    全方位對比:<b class='flag-5'>Redis</b>能取代MySQL嗎?看完這篇你就懂了

    Redis哨兵模式的自動故障檢測與主從切換實戰(zhàn)

    Redis 主從復(fù)制解決了讀擴展和數(shù)據(jù)冗余問題,但主節(jié)點故障時需要人工介入切換,這在生產(chǎn)環(huán)境中是不可接受的。Sentinel(哨兵)模式在主從架構(gòu)之上增加了自動故障檢測和故障轉(zhuǎn)移能力,是 Redis 高可用的標(biāo)準(zhǔn)方案之一。
    的頭像 發(fā)表于 02-27 11:05 ?259次閱讀

    Redis內(nèi)存管理、持久化策略與慢查詢排查分析

    Redis 在生產(chǎn)環(huán)境中承擔(dān)著緩存、會話存儲、消息隊列、分布式鎖等多種角色。隨著數(shù)據(jù)量增長和并發(fā)壓力上升,內(nèi)存碎片、持久化 I/O 抖動、慢查詢堆積這三類問題會逐漸顯現(xiàn),直接影響服務(wù)延遲和穩(wěn)定性。Redis 8.x 在內(nèi)存管理和持久化機制上做了若干改進,但核心調(diào)優(yōu)思路與
    的頭像 發(fā)表于 02-27 11:00 ?271次閱讀

    【產(chǎn)品應(yīng)用】儲能網(wǎng)關(guān)EM-1000與EM-1000G的Redis性能對比

    視頻推薦隨著儲能控制系統(tǒng)智能化發(fā)展,對實時處理和高速緩存需求提升。本測試對EM-1000與EM-1000G的Redis性能進行對比,評估其在吞吐、響應(yīng)與穩(wěn)定性上的差異,為客戶提供精準(zhǔn)硬件選型依據(jù)
    的頭像 發(fā)表于 12-02 11:39 ?455次閱讀
    【產(chǎn)品應(yīng)用】儲能網(wǎng)關(guān)EM-1000與EM-1000G的<b class='flag-5'>Redis</b>性能對比

    深度剖析Redis的兩大持久化機制

    凌晨3點,我被一通緊急電話驚醒。線上Redis集群崩潰,6GB的緩存數(shù)據(jù)全部丟失,導(dǎo)致MySQL瞬間承壓暴增,整個交易系統(tǒng)陷入癱瘓。事后復(fù)盤發(fā)現(xiàn),問題的根源竟是一個被忽視的持久化配置細節(jié)。
    的頭像 發(fā)表于 09-17 16:22 ?678次閱讀

    Redis Sentinel和Cluster模式如何選擇

    在我十年的運維生涯中,見過太多團隊在Redis集群方案選擇上踩坑。有的團隊盲目追求"高大上"的Cluster模式,結(jié)果運維復(fù)雜度爆表;有的團隊死守Sentinel不放,最后擴展性成了瓶頸。今天,我想通過這篇萬字長文,把我在生產(chǎn)環(huán)境中積累的經(jīng)驗全部分享給你。
    的頭像 發(fā)表于 09-08 09:31 ?742次閱讀

    奧比中光助力支付寶碰一下落地電梯場景

    近日,支付寶與分眾傳媒宣布聯(lián)合推出“碰一下搶紅包”服務(wù)。作為創(chuàng)新交互方式,“支付寶碰一下”首次被引入至電梯場景,并已在全國20余個城市的電梯鋪設(shè)。奧比中光作為“支付寶碰一下”業(yè)務(wù)的核心供應(yīng)商,為這一創(chuàng)新交互方式首次大規(guī)模落地電梯場景護航。
    的頭像 發(fā)表于 08-12 11:32 ?1364次閱讀

    Redis集群部署配置詳解

    Redis集群是一種分布式Redis解決方案,通過數(shù)據(jù)分片和主從復(fù)制實現(xiàn)高可用性和橫向擴展。集群將整個數(shù)據(jù)集分割成16384個哈希槽(hash slots),每個節(jié)點負責(zé)一部分槽位。
    的頭像 發(fā)表于 07-17 11:04 ?1147次閱讀

    Redis集群部署與性能優(yōu)化實戰(zhàn)

    Redis作為高性能的內(nèi)存數(shù)據(jù)庫,在現(xiàn)代互聯(lián)網(wǎng)架構(gòu)中扮演著關(guān)鍵角色。作為運維工程師,掌握Redis的部署、配置和優(yōu)化技能至關(guān)重要。本文將從實戰(zhàn)角度出發(fā),詳細介紹Redis集群的搭建、性能優(yōu)化以及監(jiān)控運維的核心技術(shù)。
    的頭像 發(fā)表于 07-08 17:56 ?1000次閱讀

    【經(jīng)驗分享】在Omni3576上編譯Redis-8.0.2源碼,并安裝及性能測試

    本文首先介紹Redis是什么,然后介紹如何在Omni3576上編譯Redis-8.0.2源碼,以及從源碼編譯、安裝Redis,最后介紹如何在Omni3576上運行Redis性能測試,并
    的頭像 發(fā)表于 06-05 08:05 ?1069次閱讀
    【經(jīng)驗分享】在Omni3576上編譯<b class='flag-5'>Redis</b>-8.0.2源碼,并安裝及性能測試

    【幸狐Omni3576邊緣計算套件試用體驗】Redis最新8.0.2版本源碼安裝及性能測試

    本文首先介紹Redis是什么,然后介紹如何在Omni3576上編譯Redis-8.0.2源碼,以及從源碼編譯、安裝Redis,最后介紹如何在Omni3576上運行Redis性能測試,并
    發(fā)表于 06-03 01:28

    HarmonyOS5云服務(wù)技術(shù)分享--云緩存快速上手指南

    Connect控制臺,在「我的項目」中選擇目標(biāo)項目,通過左側(cè)導(dǎo)航欄進入「Serverless > 云緩存」的「管理」頁簽。 ??復(fù)制關(guān)鍵參數(shù)?? ??用戶名??:直接顯示在「訪問信息
    發(fā)表于 05-22 18:37

    Redis 8 向量搜索實測:輕松擴展至 10 億向量

    艾體寶Redis 8 向量搜索實測輕松支持 10 億向量,仍保持低延遲與高吞吐。中位延遲僅200毫秒,90%精確度;處理50并發(fā)搜索請求中位延遲僅1.3秒,95%精確度。
    的頭像 發(fā)表于 05-13 14:00 ?889次閱讀
    <b class='flag-5'>Redis</b> 8 向量搜索實測:輕松擴展至 10 億向量

    Redis 再次開源!

    “ ?Redis 現(xiàn)已采用 AGPLv3 開源許可證。? ” Redis CEO 的 Blog 以下是 Redis CEO Rowan Trollope 的 Blog: 像 AWS 和 GCP 這樣
    的頭像 發(fā)表于 05-06 18:26 ?1050次閱讀