Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
RedisとGoで実装するリアルタイム通知 / Real-time notification ...
Search
hiroki.saito
January 18, 2019
Technology
0
300
RedisとGoで実装するリアルタイム通知 / Real-time notification developed by Redis and Go
hiroki.saito
January 18, 2019
Tweet
Share
More Decks by hiroki.saito
See All by hiroki.saito
なぜフルサイクルエンジニアを目指すのか / FullCycleDeveloperNight#1
hirokisaito
0
34
新規事業と技術的課題 / ROSCAFE_TECH_NIGHT12_LT
hirokisaito
0
62
GCPとPHP PHP Conference Japan 2020
hirokisaito
1
2.4k
たった1人のAPI開発 BEAR.Sundayで解決した課題たち / PHPerKaigi2019_TrackB_1445
hirokisaito
1
3.7k
5分プログラミングSlackBotとmonolog
hirokisaito
0
160
Bear.SundayとRMパターン
hirokisaito
0
280
技術力ってなんだろう
hirokisaito
0
96
新卒3年目エンジニアの生存戦略
hirokisaito
1
350
美しいショートコーディングの世界
hirokisaito
0
250
Other Decks in Technology
See All in Technology
機密情報の漏洩を防げ! Webフロントエンド開発で意識すべき漏洩パターンとその対策
mizdra
PRO
10
3.5k
「データ無い! 腹立つ! 推論する!」から 「データ無い! 腹立つ! データを作る」へ チームでデータを作り、育てられるようにするまで / How can we create, use, and maintain data ourselves?
moznion
8
4.4k
個人から巡るAI疲れと組織としてできること - AI疲れをふっとばせ。エンジニアのAI疲れ治療法 ショートセッション -
kikuchikakeru
4
1.3k
仕様駆動 x Codex で 超効率開発
ismk
2
1.5k
Service Monitoring Platformについて
lycorptech_jp
PRO
0
270
Flutterで実装する実践的な攻撃対策とセキュリティ向上
fujikinaga
2
450
JAWS-UG SRE支部 #14 LT
okaru
0
110
国産クラウドを支える設計とチームの変遷 “技術・組織・ミッション”
kazeburo
0
130
ステートレスなLLMでステートフルなAI agentを作る - YAPC::Fukuoka 2025
gfx
8
1.3k
Post-AIコーディング時代のエンジニア生存戦略
shinoyu
0
290
なぜインフラコードのモジュール化は難しいのか - アプリケーションコードとの本質的な違いから考える
mizzy
55
17k
Lazy Constant - finalフィールドの遅延初期化
skrb
0
220
Featured
See All Featured
How to Ace a Technical Interview
jacobian
280
24k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
The Straight Up "How To Draw Better" Workshop
denniskardys
239
140k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.1k
Code Reviewing Like a Champion
maltzj
527
40k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
285
14k
Unsuck your backbone
ammeep
671
58k
The Art of Programming - Codeland 2020
erikaheidi
56
14k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
54k
Scaling GitHub
holman
463
140k
How GitHub (no longer) Works
holman
315
140k
Transcript
RedisとGoで実装する リアルタイムPUSH
None
用語解説 Radiotalk 収録型の音声配信/聴アプリ 番組 ユーザーごとのラジオ番組 トーク 配信された音声 クリップ お気に入り メッセージ
Redisのメッセージ Notification FCMのメッセージ
なにをつくったのか クリップしている番組に投稿があったら通知するシステム トーカー リスナー リスナー トークを投稿 Notification
なにを解決したかったのか ニアリアルタイム - 投稿後すぐに通知したい - 投稿後に対象ユーザーにできる限り同時に届けたい 仕組みで事故を防止する - ☓ 気をつけて実行する
◦ 仕組みで事故防止 - 基本はDryRun - 重複送信/実行を防止する
システム概要 API Redis ワーカー Go CHAN NEL 投稿
なぜRedisなのか 今回はストリーム処理が不要 シンプルで高速なメッセージングキュー 社内での実績がある PHPとGoに優秀なライブラリがある
超簡単!RedisのPublishとSubscribe Subscribe SUBSCRIBE {チャンネル名} subscription := client.Subscribe("TALK_POSTED_CHANNEL") Publish PUBLISH {チャンネル名}
{メッセージ} $this->redis->publish($channel, $message);
なぜGoなのか 並列実行を簡単にできる FirebaseAdminSDKがある(もちろんCloudMessagingSDKも)
Goによるワーカー 1. メッセージの受信 2. メッセージのパース 3. メッセージからNotificationに必要な情報をDBから取得 4. Notification内容を作成 5.
FCMでNotification送信
Goでの構成 Reciver Invoker Sender Repository
送信の並列処理 go func(to string, title string, body string, data map[string]string)
{ workersChanel <- struct{}{} // この呼び出し先が実際にNotificationを送信する invoker.Sender.Send(to, title, body, data) <-workersChanel wg.Done() }(device.Token, title, body, data)
重複実行/送信を防ぐ工夫 ワーカーはメッセージを受け取ったら問答無用で送信する ただし本番環境以外はDryRun ワーカーを1つであること => Subscribeが1であること Subscribeが1 => 重複実行ではない保証
実行パフォーマンス 並列(秒) 直列(秒) 100通 2.39 23.51 1000通 23.16 231.40 10000通
233.37 2308.81 並列実行の最大数は 10に設定
今後の展望
まとめ RedisとGoで実現するリアルタイム通知 数千の規模であればワーカー1つでも実用性はある 規模によりますが、このシンプルな構成は実装も楽でオススメ