總摘要: 直播. 代理. 面試分享.事務(wù)方案. 秒殺方案. json動(dòng)態(tài)轉(zhuǎn)DTO. 打開大文件卡死. 網(wǎng)站被刷. 接口可用行. 排序. 數(shù)據(jù)庫存錢. 線程數(shù). 秒殺. 潛力標(biāo)準(zhǔn)分享. CPU高排查. 壓測. kafka丟信息. java IO模型.
2017-11-20
- 摘要: 直播. 代理. 面試分享.
1. 我發(fā)現(xiàn)群里沒有關(guān)于直播流，RTMP協(xié)議等資料，我想問做視頻實(shí)時(shí)直播要用到哪些技術(shù)棧，給點(diǎn)提示我去找找就行。目前我就知道要走 RTMP協(xié)議，但是 具體Java實(shí)現(xiàn)方案一直未果。[小護(hù)士]
三方: 趣拍sdk
技術(shù): webRTC
2. 反向代理就是一個(gè)負(fù)載均衡？反向代理的反向什么意思？[杭州-船長]
正向代理可以做客戶端負(fù)載均衡，反向代理可以做服務(wù)端負(fù)載均衡。 正向代理是本地環(huán)境設(shè)置一個(gè)代理，例如win32 的 hosts文件代理，就是一種. 反向代理是服務(wù)器遠(yuǎn)程環(huán)境設(shè)置一個(gè)代理，例如nginx寫個(gè)配置 location 一下，就是一種.一般沒人說正向代理，默認(rèn)說的代理就是正向代理.[廣州-小護(hù)士] .
其實(shí)正向反向，就是客戶端知不知道接受自己請(qǐng)求的是個(gè)什么玩意兒. 知道自己請(qǐng)求的是個(gè)代理，那就是正想代理.不知道自己請(qǐng)求的是個(gè)代理，以為是個(gè)服務(wù)器，那就是反向代理（這個(gè)代理會(huì)把請(qǐng)求轉(zhuǎn)到事實(shí)服務(wù)器上）.[北京-戰(zhàn)斗].
--- nginx 為方向代理.
3. 成都馬上金融面試分享.[成都-獻(xiàn)計(jì)獻(xiàn)策]
- ZeroCopy 是什么？
- JVM虛擬機(jī)的垃圾回收算法
- 偏向鎖 自旋鎖
- 數(shù)據(jù)庫同步方案 binlog
- 怎么理解原子性和可見性
- SQL 調(diào)優(yōu)策略 索引相關(guān)實(shí)現(xiàn)和向左原則
- Kafka設(shè)計(jì)原理
- Kafka 內(nèi)部 偏移量如何同步（例如A機(jī)器 offset100 B機(jī)器 95 C機(jī)器98） ISR協(xié)議？
- 服務(wù)化治理
- 如何設(shè)計(jì)高可用系統(tǒng)，從業(yè)務(wù)的角度出發(fā)呢，例如降級(jí)
- Java容器 如何做容錯(cuò)的？ 例如HashMap 或者List 容器 在刪除數(shù)據(jù)的時(shí)候，如何避免出錯(cuò)
- 如何監(jiān)控線上系統(tǒng)問題
--- CPU 100%
--- 內(nèi)存溢出- 如何排查線上系統(tǒng)性能問題，MySQL 慢查詢
2017-11-21
- 摘要: 事務(wù)方案. 秒殺方案.
1. **單JVM跨庫的替代事務(wù)的方案, 和跨應(yīng)用多JVM的替代事務(wù)方案, 有區(qū)別性的考量么?[北京-屁顛顛]
有區(qū)別.為了管理事務(wù)，實(shí)際上需要有個(gè)中心。 單JVM的情況下，雖然是多數(shù)據(jù)源，但該JVM本身肯有作為中心. 跨應(yīng)用的情況下，中心的選擇就比較麻煩了，一般會(huì)專門做一個(gè)中心. 所以單JVM的情況下，一些java中間件可以做，比如sharding-jdbc.
北京-屁顛顛(-) 10:26:01
怎么做中心？這個(gè)中心的作用是啥？
北京-喜(-) 10:26:23
你說的是替代。我前面說的是區(qū)別，尷尬
北京-喜(-) 10:27:08
代替方案的區(qū)別， 和他們事務(wù)本身的區(qū)別很類似, 跨應(yīng)用的問題，就是失敗誰感知，以及補(bǔ)償?shù)降渍l來做
北京-屁顛顛(-) 10:27:47
嗯，這個(gè)知道
北京-喜(-) 10:27:51
是當(dāng)前應(yīng)用感知和內(nèi)部做補(bǔ)償。 還是上游節(jié)點(diǎn)
北京-屁顛顛(-) 10:28:32
跨應(yīng)用比較常見，一般是mq+輪詢來做
杭州-Freedom(-) 10:28:40
@北京-喜 多jvm，不能用sharding-jdbc吧，一般會(huì)采用什么方案
成都-梅小西(-) 10:28:49
喜神，多個(gè)應(yīng)用下+多個(gè)db的情況下還要做中心么
北京-喜(-) 10:28:57
額外加個(gè)失敗存儲(chǔ), 延遲隊(duì)列、任務(wù)庫 都可以
,如果有工作流，工作流也可以做,
強(qiáng)事務(wù)需要做中心
成都-梅小西(-) 10:33:01
風(fēng)險(xiǎn)大，而且性能不高
北京-喜(-) 10:38:01
一般面試能說出來有補(bǔ)償，在說下方案就可以了, 稍微高端點(diǎn)的做法是 任務(wù)庫+觀察者模式
成都-梅小西(-) 10:40:28
啥叫任務(wù)庫+觀察者
北京-喜(-) 10:41:24
就是封裝1個(gè)任務(wù)庫，可以跨業(yè)務(wù)支持任務(wù)調(diào)度, 補(bǔ)償本質(zhì)上 就是重復(fù)性執(zhí)行一個(gè)任務(wù), 觀察者模式 這個(gè) 叫 監(jiān)聽者吧，觀察者不準(zhǔn)確.
北京-喜(-) 10:42:51
任務(wù)庫 有自身的批處理引擎，發(fā)現(xiàn)目標(biāo)任務(wù)后，回調(diào)業(yè)務(wù)進(jìn)行補(bǔ)償，API是標(biāo)準(zhǔn)的和消息監(jiān)聽一模一樣差別就是有引擎，有task 模型
北京-喜(-) 10:43:58
簡單理解：就是那個(gè)掃描任務(wù)的變成線程
成都-梅小西(-) 10:44:25
補(bǔ)償任務(wù)包含人工處理么
北京-屁顛顛(-) 10:44:30
有點(diǎn)像跑流水, 感覺
成都-梅小西(-) 10:44:35
你說的重試，是代碼自動(dòng)重試吧
北京-喜(-) 10:44:36
可以, 我說的是平臺(tái)型的, 和跑流水那個(gè)一樣，可以處理這一類, 那就是 單次任務(wù)嘛
天津-coffee(-) 10:45:24
這個(gè)引擎 你們用啥組件么？或者中間插件啥的 ？
北京-喜(-) 10:45:43
引擎是個(gè)高大上的說法
成都-勇(-) 10:45:53
補(bǔ)償平常都是要自己調(diào)用，這個(gè)任務(wù)庫是不是就是相關(guān)于搞一個(gè)公共的平臺(tái)，按照標(biāo)準(zhǔn)來做，它自己就能調(diào)用
北京-喜(-) 10:46:13
其實(shí)就是 掃描任務(wù)、發(fā)現(xiàn)目標(biāo)任務(wù)、查找到客戶端、調(diào)用客戶端、管理執(zhí)行結(jié)果和任務(wù)的基礎(chǔ)屬性
深圳-平凡(389918256) 10:46:33
北京-喜(-) 10:47:01
類似, 這個(gè)帶log, 帶log可以做些不同的事情
天津-coffee(-) 10:47:24
這么聚合型的業(yè)務(wù) ，我們系統(tǒng)也急需這樣一套 東西.
北京-喜(-) 10:50:35
把平凡那個(gè)圖稍微改一改 就是我說的那個(gè),加個(gè)task scanner, 從某個(gè)存儲(chǔ)擼目標(biāo)任務(wù)出來，
比如DB、tair等， 然后執(zhí)行task runner, runner內(nèi) look up client consumer , 然后 invoke consumer
深圳-平凡(-) 10:52:13
事物的中心化管理 和 去中心化管理?？梢詤⒖約aga和昨天那本AKKA
北京-喜(-) 10:52:17
client 拿到任務(wù)，做與之對(duì)應(yīng)的補(bǔ)償事情, 中心化 的瓶頸在于中心的穩(wěn)定性. 我建議還是想方案的時(shí)候，
先想中心類的，有助于提煉問題本質(zhì)，全局考慮, 實(shí)操的時(shí)候，采用本地的
深圳-平凡(-) 10:54:18
@北京-喜 美團(tuán)分布式事務(wù)都是基于這種中心化的嗎？
北京-喜(-) 10:54:31
沒有分布式事務(wù), 有也沒人用的
深圳-平凡(-) 10:56:21
比如訂單域發(fā)起一個(gè)訂單創(chuàng)建成功的事件以后，后面就不用管哪個(gè)消費(fèi)者關(guān)心這個(gè)事件，以及消費(fèi)者處理自身事務(wù)的情況？
北京-喜(-) 10:56:43
這個(gè)看業(yè)務(wù)
天津-coffee(-) 10:57:04
想知道一下，你們怎么管理事務(wù)的?
北京-喜(-) 10:57:14
理論上是用事件機(jī)制 + 回調(diào) 機(jī)制處理的, 圖書館還還書的例子啊, 學(xué)生去圖書館還書，管理員會(huì)先處理完學(xué)生端事情，
比如處理學(xué)生卡名下的借書記錄，歸還系統(tǒng)庫存，然后就可以叫學(xué)生回去了, 然后他會(huì)給自己標(biāo)記個(gè)事件在腦子里，比如
需要把書放回到書架, 這個(gè)時(shí)候他可以自己找空閑事件去做， 也可以一嗓子喊下張三(專門整理書架的人)
過來拿書, 假如張三不在，他可能會(huì)過一會(huì)在喊張三(比如5分鐘之后)
成都-梅小西(-) 11:00:21
也就是說，調(diào)用另外一個(gè)服務(wù)就算失敗也不影響自己的服務(wù)結(jié)果？
成都-梅小西(-) 11:00:30
只是記錄下
北京-喜(-) 11:00:31
受理 + 處理模型
成都-梅小西(-) 11:00:37
然后后續(xù)重試？
北京-喜(-) 11:00:42
受理結(jié)束，就是一個(gè)階段完畢, 處理一般是另外一個(gè)階段，通常是2個(gè)領(lǐng)域的事情, 比如用戶退款，需要?dú)w還庫存
成都-梅小西(-) 11:01:11
那這樣造成數(shù)據(jù)不一致咋辦
北京-喜(-) 11:01:18
自處理啊, 比如訂單端發(fā)起退款操作請(qǐng)求的處理，然后調(diào)用庫存，庫存先受理這個(gè)請(qǐng)求，
表示接到了, 然后庫存系統(tǒng)會(huì)標(biāo)記自己有個(gè)任務(wù)，就是歸還XX庫存。庫存系統(tǒng)會(huì)自己去處理這個(gè)任務(wù)的, 自己保證結(jié)果
成都-梅小西(-) 11:02:28
所以中間這個(gè)過程是允許數(shù)據(jù)不一致是把, 比如正在處理中
北京-喜(-) 11:02:38
不是數(shù)據(jù)不一致, 是視角的問題, 你是在上帝視角上, 不是在領(lǐng)域視角, 專人專事
深圳-平凡(-) 11:03:48
要深刻明白這個(gè)道理就看Actor，如果是業(yè)務(wù)級(jí)的Actor那就要深入理解DDD里的各種模式之間的關(guān)系，尤其是上下文和聚合.
**<<Akka 應(yīng)用模式: 分布式應(yīng)用程序設(shè)計(jì)實(shí)踐指南>>**
西安-大蒜(-) 11:04:15
這個(gè)做法，感覺像是排隊(duì)指令下發(fā)的套路
北京-喜(-) 11:04:25
全局看的，流程設(shè)計(jì)的全是串行的, 所以前后產(chǎn)生很重的依賴
西安-大蒜(-) 11:05:12
允許最終一致, 客戶端并不知道何時(shí)返回結(jié)果
北京-喜(-) 11:05:49
實(shí)際上物理世界是有大量的并行和異步的,銀行匯款就是啊
西安-大蒜(-) 11:06:03
被調(diào)用方異步響應(yīng)
北京-屁顛顛(-) 11:06:14
落實(shí)這東西成本會(huì)很高吧，boss 不會(huì)批的
北京-喜(-) 11:06:29
請(qǐng)求、受理、應(yīng)答；處理、再應(yīng)答
西安-大蒜(-) 11:07:40
@北京-喜 你這個(gè)最后一步再應(yīng)答是怎么做的？
蘇州-一樹梨花啊(-) 11:07:46
不用框架可以自己簡單的做一下
北京-喜(-) 11:07:49
看業(yè)務(wù), 就是處理結(jié)果 如果前臺(tái)需要知道的話,可以是廣播啊
西安-大蒜(-) 11:08:15
是被調(diào)用方處理完后把結(jié)果存儲(chǔ)起來，等待調(diào)用方去查找嗎？
北京-喜(-) 11:08:19
也可以前臺(tái)自己輪
深圳-平凡(-) 11:08:37
如果是玩Actor就用DDD+AXON。如果玩中心就用saga，華為最近開源了他們的微服務(wù)框架ServicComb，其中就實(shí)現(xiàn)了ServiceComb-saga
北京-喜(-) 11:08:44
進(jìn)來后臺(tái)不調(diào)用前臺(tái), 盡量
深圳-平凡(-) 11:09:16
不管中心還是非中心化，結(jié)合DDD的模式才是最好的落地方式.
2. 誰做秒殺的可以來講講么. [天津-coffee]
北京-小白楊<-> 16:38:41
請(qǐng)求進(jìn)來分配token, token分配完再進(jìn)來的數(shù)據(jù)直接丟棄
北京-漫游(-) 16:40:12
我們用redis的decr，直接扣減，返回結(jié)果小于0的就失敗, 扣減成功后其實(shí)就是寫訂單等數(shù)據(jù)了
成都-梅小西(-) 16:43:41
秒殺的重點(diǎn)是怎么擋住99%的請(qǐng)求, 不讓進(jìn)入db, 前端，路由，消息等各種系統(tǒng)先把請(qǐng)求擋住,
可以學(xué)魅族商城的秒殺方案, 用redis獲取token
成都-梅小西(-) 18:25:33
秒殺情況下，請(qǐng)不要輕易用db的鎖來控制, 不然就等著dba跳樓吧
廣州-香蒲(-) 18:25:44
一般認(rèn)為競爭很少或者不會(huì)輕易產(chǎn)生競爭的時(shí)候 用樂觀鎖
成都-梅小西(-) 18:25:55
也不對(duì)，是有個(gè)前提條件,就是你能保證90%以上的請(qǐng)求不會(huì)達(dá)到db，那么剩下的你走db的鎖，可以接受.
你要是不攔截，直接用db去控制，dba會(huì)殺了你
廣州-小護(hù)士<-> 18:27:02
秒殺一般不是先走緩存，異步更新db么
成都-梅小西(-) 18:27:20
也可以啊。也是一種方案, 只要你別拿db去硬抗, 用緩存，用隊(duì)列，用路由過濾，前端過濾等等都是方法.
<<高可用架構(gòu)>>
上海-給你們(-) 20:39:49
秒殺的重點(diǎn)是 秒殺商品找 隨機(jī)參與人。記住這個(gè)邏輯就不會(huì)錯(cuò)
2017-11-22
摘要: json動(dòng)態(tài)轉(zhuǎn)DTO. 打開大文件卡死.
1.solr的一個(gè)問題 數(shù)據(jù)采集系統(tǒng)給我一個(gè)json串，對(duì)應(yīng)于我的solr schema，schema里面有一個(gè)是動(dòng)態(tài)字段price_shopcode，意思就是每個(gè)sku在每個(gè)店鋪的價(jià)格是不一樣的，我在添加索引的時(shí)候，首先要把這個(gè)json串轉(zhuǎn)換成自己的DTO對(duì)象，但是由于是動(dòng)態(tài)字段，所以有很多的字段，5000個(gè)店鋪就要5000個(gè)字段，而且只要有新店鋪入住，就要改代碼，麻煩問問這個(gè)應(yīng)該怎么設(shè)計(jì)才好?[南京-阿輝]
北京-哇咔咔(-) 22:39:38
每個(gè)sku在每個(gè)店鋪的價(jià)格不一樣，但是可以都使用一個(gè)叫做price的字段存啊，為什么5000個(gè)店鋪就要用5000個(gè)字段
北京-韭菜盒子(-) 22:52:47
我也遇到過這種場景,當(dāng)時(shí)的做法是,盡可能的找出通用字段,會(huì)涉及到搜索排序的
北京-韭菜盒子(-) 22:53:01
其他直接在Mongo或者mysql存?zhèn)€json
北京-韭菜盒子(-) 22:53:08
不支持按這個(gè)字段查詢排序
北京-韭菜盒子(-) 22:53:32
因?yàn)閿U(kuò)展字段有個(gè)弊病是,同名,但未必同類型
北京-韭菜盒子(-) 22:53:53
es不支持同名字段但是不同類型
北京-韭菜盒子(-) 22:54:07
除非強(qiáng)轉(zhuǎn)字符串,但是強(qiáng)轉(zhuǎn)字符串無法排序
北京-哇咔咔(-) 23:01:21
復(fù)雜的不需要計(jì)算和查詢 的字段可以存json
北京-哇咔咔(-) 23:02:08
需要用來查詢的可以定義屬性名和屬性值表，在sku保存這個(gè)sku的屬性值id連接成的字符串
2. jvisualvm 這個(gè)能像java一樣指定內(nèi)存大小嗎?我現(xiàn)在用這個(gè)工具打開個(gè)500M的堆直接卡死, 有什么方法能解決這個(gè)工具,打開大文件卡死問題? [北京-韭菜盒子]
北京-哇咔咔(-) 23:03:08
mat可以解決你的問題
北京-哇咔咔(-) 23:04:56
可以jhat線上的dump文件，然后用瀏覽器看
北京-韭菜盒子(-) 23:05:21
jmap還可以grep看
北京-韭菜盒子(-) 23:05:26
感覺比jhat方便
北京-哇咔咔(-) 23:05:47
沒有圖形界面，還沒有oql
2017-11-23
- 摘要: 網(wǎng)站被刷. 接口可用行. 排序. 數(shù)據(jù)庫存錢. 線程數(shù). 秒殺. 潛力標(biāo)準(zhǔn)分享. CPU高排查.
1. 網(wǎng)站被刷有什么手段嗎？運(yùn)維封了幾個(gè)百ip了[中山-劃船]
珠海-阿狗(-) 8:55:07
ip限制和圖形驗(yàn)證碼，手機(jī)號(hào)頻率。[極驗(yàn)驗(yàn)證]
杭州－東子(-) 8:54:48
你隨意加個(gè)驗(yàn)證操作，破解的人，破解難度就需要成倍增加了, 你不用糾結(jié)能不能破解，你只要讓自己破裂難度增大了，他就會(huì)去找破裂難度不大的網(wǎng)站了
2. 現(xiàn)在有個(gè)需求 就是某個(gè)服務(wù)有20個(gè)接口 有5個(gè)核心接口 15個(gè)非核心接口, 現(xiàn)在在高峰期想保證5個(gè)核心接口的可用性，訪問15個(gè)非核心接口直接返回或者跳轉(zhuǎn).[北京-高天悅]
北京-高天悅(-) 9:25:05
30萬用戶 同時(shí)12：00 開始操作, 都寫
成都-淡(-) 9:25:34
那11點(diǎn)50的時(shí)候申請(qǐng)臨時(shí)服務(wù)器啊
成都-淡(-) 9:27:05
瓶頸在哪
北京-高天悅(-) 9:27:08
數(shù)據(jù)庫主從非集群, 每次高峰 數(shù)據(jù)庫延遲達(dá)幾十秒 ,目前用redis作為分布式鎖 ,某樣物品 一個(gè)用戶選了 另一個(gè)用戶一定不能選 , 現(xiàn)在有redis緩存 但是mysql還是扛不住 , 一個(gè)主從庫
成都-奮斗(-) 9:32:12
如果異步寫庫，不會(huì)存在他說的那種問題吧。
北京-高天悅(-) 9:33:04
12：00開始 放開訪問, 30萬用戶就來搶了
成都-梅小西(-) 9:33:51
首先，我建議你分庫，不要放一個(gè)庫，比如訂單一個(gè)庫，用戶一個(gè)庫。然后每個(gè)庫一主，2從，然后高分期，先寫緩存，然后定期寫db
北京-高天悅(-) 9:35:25
類似秒殺 不過比秒殺麻煩點(diǎn)兒, 一張表大約3000萬到4000萬條數(shù)據(jù) 不過熱點(diǎn)數(shù)據(jù)會(huì)提前打入Redis
北京-高天悅(-) 9:46:15
就是現(xiàn)在短時(shí)間沒找到原因 暫時(shí)想用人工開關(guān)降級(jí)來應(yīng)對(duì)一下
北京-高天悅(-) 9:58:06
服務(wù)降級(jí)可以放在NGINX走嗎
廣州-小護(hù)士<-> 9:58:55
貌似要寫插件
3, 餓了么、美團(tuán)，那些距離排序是咋完的，而且還帶分頁的 ，難道是一次性全部排完？ 在按前端翻頁需求加載？[上海-NICE]
北京-哇咔咔(-) 14:10:40
R 樹索引
北京-哇咔咔(-) 14:11:24
或者先按geohash計(jì)算，再把符合geohash的數(shù)據(jù)按距離排序
北京-哇咔咔(-) 14:11:54
但是這個(gè)做法不夠準(zhǔn)確，不過能滿足一般情況
上海-NICE(-) 14:12:20
或者先按geohash計(jì)算 ？全部計(jì)算好？
北京-哇咔咔(-) 14:12:36
保存的時(shí)候就算了geohash，并保存下來
北京-哇咔咔(-) 14:13:20
查詢的時(shí)候按用戶經(jīng)緯度的geohash查出來，再計(jì)算符合這個(gè)geohash的所有數(shù)據(jù)的距離，緩存下來
成都-孤狼(-) 14:13:27
保存經(jīng)度維度，geohash
成都-孤狼(-) 14:13:35
匹配的時(shí)候只匹配geohash
北京-哇咔咔(-) 14:13:57
geohash不能按距離排序，只能計(jì)算大致范圍, 可以把geohash計(jì)算到很高的精度，這個(gè)精度控制的好也能模擬出一個(gè)大致準(zhǔn)確的結(jié)果，然后模擬出類似按距離排序的結(jié)果, 再精確的結(jié)果就是R樹索引，是在B+樹的基礎(chǔ)上對(duì)空間數(shù)據(jù)的擴(kuò)展
上海-NICE(-) 14:16:21
行，我去看看
北京-哇咔咔(-) 14:20:19
R樹索引有點(diǎn)復(fù)雜，需要精通磁盤IO和文件系統(tǒng)特性才能做的好
4, 對(duì)了，昨天群里討論的錢在數(shù)據(jù)庫里存什么，是什么結(jié)果？分的整數(shù)？[中山-劃船]
中山-劃船(-) 14:31:46
我們目前是分的整數(shù)，不過以后應(yīng)該會(huì)改成 小數(shù)點(diǎn) 元
廣州-小護(hù)士<-> 14:40:23
重點(diǎn)不是怎么存錢~, 重點(diǎn)是把錢分級(jí)
北京-漫游(-) 14:40:40
為啥要改成小數(shù)點(diǎn)？[整數(shù)轉(zhuǎn)起來麻煩]
北京-喜(-) 14:41:04
看你把錢看成是個(gè)數(shù)字 還是個(gè)模型, 如果是模型，額度只是它的一個(gè)屬性,
精度、單位等也是屬性
廣州-小護(hù)士<-> 14:42:25
嚴(yán)格來講都是存long，最小位單位為分
北京-漫游(-) 14:43:21
電商一般都是這么做, 互金要求精度比較高, 我之前公司是存小數(shù)，不知道有沒有存bigint的公司
北京-哇咔咔(-) 14:44:44
我們有些供應(yīng)商要求錢精確到小數(shù)點(diǎn)后四位的, 所以只算到分是不行的, 存double/float也是不行的，丟精度的
5, 核心線程數(shù) 最大線程數(shù) 隊(duì)列大小 跟cpu核心 有沒有一個(gè)可行的公式? [杭州-所長]
杭州-所長(-) 15:21:41
我想問的是ThreadPoolExecutor 參數(shù)之間的關(guān)系, corePoolSize maximumPoolSize BlockingQueue容量關(guān)系? 比如我設(shè)想 三個(gè)參數(shù)分別是 8,16,32.
成都-勇(-) 15:23:12
http://www.infoq.com/cn/articles/Java-Thread-Pool-Performance-Tuning/
北京-coder-在線教育(673101378) 15:23:12
隊(duì)列滿了就用16了
6, excel導(dǎo)入展示在頁面，只能用poi吧？[山西-小龍]
北京-coder-在線教育(-) 15:34:25
也可以用js
山西-小龍(-) 15:38:35
jxls不能實(shí)現(xiàn)吧？
北京-屁顛顛(-) 15:39:51
js 不行吧
北京-coder-在線教育(-) 15:40:42
我都實(shí)現(xiàn)過, 直接讀excel文件, 沒有node.js的東西，純客戶端js
7, 漫談秒殺設(shè)計(jì).
北京-喜(-) 16:11:42
秒殺背后的邏輯是：流量怎么抗, 有多少個(gè)拋出拒絕異常的？
北京-喜(-) 16:12:03
你1個(gè)應(yīng)用 做這么多事， 你設(shè)計(jì)的再好，意義也不大, 抗流量的應(yīng)用，性能一定要好
北京-屁顛顛(-) 16:12:31
一般 redis 做排隊(duì)吧
北京-喜(-) 16:12:39
這就是為什么需要有很多的預(yù)熱和預(yù)先分配, 不是過程中實(shí)時(shí)計(jì)算
上海-大文(-) 16:13:06
外層限流，內(nèi)部做隊(duì)列
北京-喜(-) 16:13:32
最后才是 庫存怎么控制
北京-金木犀(-) 16:14:25
一般這種秒殺系統(tǒng)怎么設(shè)計(jì)，有哪些坑，可以介紹一下嗎？
廣州-小護(hù)士<-> 16:14:27
用token申請(qǐng)+校驗(yàn)token， 入庫 - 1
北京-喜(-) 16:15:00
前面說了 2層啊, 1層是流控層 1層是交易層, 絕對(duì)不是一個(gè)應(yīng)用 不是一個(gè)集群, 如果只有1個(gè)應(yīng)用，掛在最前面 既抗流量又做交易, 交易做的下去么？ 流量會(huì)把資源打垮.
北京-金木犀(-) 16:18:39
其實(shí)我更想知道，抗流量如何去劃分，怎么去設(shè)計(jì)能保證服務(wù)正常，然后在就是第2層的設(shè)計(jì)
北京-屁顛顛(-) 16:20:37
還沒熟悉業(yè)務(wù)前，不要大動(dòng)作
北京-喜(-) 16:20:52
流量怎么 和你怎么抗讀流量是一樣的, 只不過按照業(yè)務(wù)特點(diǎn)，有些會(huì)是漏斗的, 給到交易的，基本已經(jīng)是目標(biāo)流量了, 可以有1-2倍的buffer, 比如20個(gè)庫存，放40個(gè)進(jìn)來
廣州-小護(hù)士<-> 16:22:52
@北京-喜 是不是先要給用戶分發(fā)token？然后提交訂單校驗(yàn)token，隊(duì)列傳入庫存系統(tǒng)，庫存-1，返回訂單成功, 限流主要在分發(fā)token那里做
北京-喜(-) 16:23:10
目標(biāo)用戶才發(fā)token, 這個(gè)是安全性的要求, token發(fā)的比庫存多, token發(fā)完 基本等于活動(dòng)結(jié)束
北京-哇咔咔(-) 16:26:02
為什么token要比庫存多，而不是一樣？ [交易的成功率,留buffer]
廣州-小護(hù)士<-> 16:26:08
@北京-喜 token是不是都要預(yù)先生成，然后分配到各個(gè)節(jié)點(diǎn)做本地緩存，用戶進(jìn)來其中一個(gè)節(jié)點(diǎn)后就去拿token？？
北京-喜(-) 16:26:17
這樣最好, 提升性能
廣州-小護(hù)士<-> 16:27:16
token比庫存多是因?yàn)橐A(yù)防有些人撤單, 撤單的人已經(jīng)占用了token，稱為無效token [這個(gè)是業(yè)務(wù)規(guī)則，有的秒殺必須支付]
北京-喜(-) 16:29:35
這個(gè)場景下說的隊(duì)列，是營造一種庫存排隊(duì)的感覺出來, 如果一單只能買一個(gè)，讓token跟庫存一樣多，發(fā)一個(gè)token，就肯定能買一個(gè)。這樣不是更好, 其實(shí)是需要一定的并行處理能力的。 單MQ，consumer中需要異步處理，避免擁堵
北京-喜(-) 16:30:45
對(duì)交易流程和成功率有信心可以, 這個(gè)還要看對(duì)失敗的交易的態(tài)度, 是補(bǔ)償 還是 丟棄
杭州-所長(-) 16:31:22
話說rabbitMQ 如何設(shè)置并行消費(fèi)?
北京-喜(-) 16:31:34
先ack
廣州-小護(hù)士<-> 16:34:19
ack？握手？
北京-喜(-) 16:34:27
先 ack consume success, 給broker
上海-小安(-) 16:55:29
用戶搶購的時(shí)候，會(huì)去查詢庫存，這時(shí)候如何保證剩余庫存的實(shí)時(shí)性呢？
北京-永恒(-) 16:57:02
redis 鎖
北京-喜(-) 16:57:46
1個(gè)是 不一定查的是庫存， 2個(gè)是即便查的庫存和實(shí)時(shí)性關(guān)系不大。 流量遠(yuǎn)超庫存
上海-小安(-) 17:00:29
@北京-喜 嗯嗯，明白了，搶購的時(shí)候，流量遠(yuǎn)超庫存，要庫存也沒啥用了
成都-梅小西(-) 17:00:36
只要保證不超賣就行了
北京-喜(-) 17:00:45
流量和庫存的關(guān)系 是這樣, 還有另外一層原因, 秒殺和正常售賣的入口規(guī)則不一樣, 正常售賣 是 有庫存才展示給用戶的, 秒殺是 先開放，動(dòng)態(tài)分, 是活動(dòng)維度, 活動(dòng)下面才是商品, 雖然用戶看起來都一樣 好像都是商品
上海-小安(-) 17:03:52
嗯嗯，維度確實(shí)不一樣，謝謝啦，我剛才搞混啦
廣州-小護(hù)士<-> 17:04:21
秒殺不展示庫存吧~
北京-喜(-) 17:05:49
展示不展示 秒殺結(jié)束展示活動(dòng)已結(jié)束還是售罄, 都是業(yè)務(wù)細(xì)節(jié)了, 活動(dòng)已結(jié)束是活動(dòng)維度 售罄是庫存溫度
廣州-小護(hù)士<-> 17:06:37
我意思是沒有實(shí)時(shí)展示庫存~
北京-喜(-) 17:06:53
沒有實(shí)時(shí)庫存
北京-喜(-) 17:09:04
拼單沒有秒殺. 這些業(yè)務(wù) 和 訂單、庫存系統(tǒng) 有關(guān)系，但是又沒直接關(guān)系, 拼單、秒殺、正常售賣、各種分享贈(zèng)送等都是業(yè)務(wù)[這些都可以復(fù)用交易、訂單、商品、庫存、價(jià)格、支付、結(jié)算/清算等系統(tǒng). 我是想說這個(gè)，只有理解了這個(gè)，才會(huì)理解阿里的。 不然別人說了原因，你還是不知道]. 訂單和商品系統(tǒng)、庫存系統(tǒng)是下面的原子服務(wù), 然后大家可以去理解下阿里的前中后臺(tái)架構(gòu).
上海-MrString(-) 17:12:37
我有一個(gè)疑惑 為啥現(xiàn)在很多電商行業(yè)重心都在拼單上面呢？
西安-hopeAngel(-) 17:12:59
因?yàn)槠磫慰梢钥帐痔装桌?br> 廣州-小護(hù)士<-> 17:13:11
因?yàn)槠磫味噘u, 供應(yīng)商也好做批發(fā)
北京-喜(-) 17:14:23
物流也是錢啊
8, 喜神你學(xué)業(yè)務(wù)看哪些書籍？[深圳-平凡]
北京-喜(-) 17:33:08
擦，這個(gè)我沒辦法. 我只能劇透1個(gè)技術(shù)團(tuán)隊(duì)判斷具體某個(gè)同學(xué)潛力的標(biāo)準(zhǔn)
深圳-hanson(-) 17:34:37
標(biāo)準(zhǔn) 是對(duì)業(yè)務(wù)理解？
北京-喜(-) 17:34:45
不是，是聰明, 第二個(gè)標(biāo)準(zhǔn)是心態(tài). 心態(tài) 1個(gè)是積極性 1個(gè)是心智(包容性、換位、持久性等). 聰明與否，覺得高度上限. 心態(tài)好與差，決定能不能達(dá)到這個(gè)上限. 聰明就是傳統(tǒng)的聰明.
南寧-為兩餐(-) 17:49:57
所在平臺(tái)對(duì)能達(dá)到的高度有影響啊
北京-喜(-) 17:50:17
有影響 不是絕對(duì)影響, 先是人 然后才是環(huán)境 不要搞反了
南寧-為兩餐(-) 17:51:09
人也是要環(huán)境中成長吧
北京-喜(-) 17:51:21
差的環(huán)境也可以啊, 這個(gè)就是心態(tài).
北京-喜(-) 17:52:00
去哪里工作都是解決問題的. 問題是解決的什么難度的問題, 什么類型的問題. 技術(shù)同學(xué)容易 眼里只有技術(shù)問題, 認(rèn)為其他的問題，都是別人的坑, 大多數(shù)思想都是事不關(guān)己 高高掛起[這是思維的局限，跟個(gè)性也有關(guān)系。甩鍋是不行的], 所以會(huì)有天花板, 不管走技術(shù)路線 還是 管理路線, 后期都是要通過別人拿結(jié)果， 過程也不會(huì)一帆風(fēng)順。 需要有好心態(tài)、抗挫折，扭轉(zhuǎn)局面的能力.
9, CPU高問題排查
杭州－東子(-) 21:16:48
那個(gè)線上cpu百分百我遇到過倆次
杭州－東子(-) 21:19:13
第一次估計(jì)是部署時(shí)候服務(wù)器有問題
杭州－東子(-) 21:19:31
第二次肯定有人代碼有問題
北京-foryous(-) 21:19:41
我的storm集群前段時(shí)間經(jīng)常cpu百分九十以上
杭州-Freedom(-) 21:19:45
我最近排了N次的CPU 100%、內(nèi)存泄漏，感覺這塊的技能樹點(diǎn)了很多
杭州－東子(-) 21:23:43
Kafka 內(nèi)部 偏移量如何同步（例如A機(jī)器 offset100 B機(jī)器 95 C機(jī)器98） ISR協(xié)議？
杭州-Freedom(-) 21:21:36
@杭州-emoji 群里的java問題排查手冊，是神作, 另外，谷歌下 java cpu 100%、內(nèi)存泄漏，看看相關(guān)文章、經(jīng)驗(yàn)、思路. 另外，推薦你假笨的微信公眾號(hào)，也有相關(guān)文章分享.
北京-foryous(-) 21:27:31
我遇到cpu很高的時(shí)候，內(nèi)存也使用很高，機(jī)器負(fù)載高，然后一直在fullgc
中山-劃船(-) 21:29:55
cpu100% 就多jstack幾次，看看跑的哪行代碼，基本就O了
杭州-Freedom(-) 21:36:23
如何定位消耗CPU最多的線程
2017-11-24
- 摘要: 壓測. kafka丟信息. java IO模型.
1, 最近搞壓測，被壓方法調(diào)用一次rpc方法，讀一次數(shù)據(jù)庫，寫入一次數(shù)據(jù)庫（mysql innodb RR），我跟蹤了每個(gè)步驟的耗時(shí)，凡是單次操作超過100ms的都打印log，后來發(fā)現(xiàn)這些打印的log中rpc耗時(shí)最遲的可以達(dá)到200+ms，數(shù)據(jù)庫讀取最遲可達(dá)到1000ms，寫入操作最遲可以達(dá)到500ms，出現(xiàn)這種情況首先聯(lián)想到的是連接池不夠用，所以rpc和數(shù)據(jù)庫的連接池連接數(shù)都適當(dāng)調(diào)大，可是qps并沒有提升，打印出來的log也沒有下降。。還有什么其他原因嗎？網(wǎng)絡(luò)抖動(dòng)？[上海-大文]
上海-大文(-) 10:52:05
①進(jìn)入程序-------->②查詢數(shù)據(jù)庫------->③調(diào)用rpc------->④寫入數(shù)據(jù)庫
以上正常情況下都可以在50ms甚至30ms內(nèi)完成，但是qps一直上不去，所以就打了log查看，把單次調(diào)用超過100ms的打印出來，發(fā)現(xiàn)在②③④處均有延遲的情況
北京-EP查水表(-) 10:53:35
你qps多少啊？有多少個(gè)服務(wù)線程？
上海-大文(-) 10:53:59
開了70個(gè)線程循環(huán)調(diào)用, qps測出來在500～700左右
北京-EP查水表(-) 10:56:04
沒明白……，其實(shí)你qps的話，用 1000/平均響應(yīng)時(shí)間 * 線程數(shù)，大致就能算出來啊, 或者反推響應(yīng)時(shí)間，看是否符合預(yù)期, 不是看你幾個(gè)線程調(diào)用，是看服務(wù)端幾個(gè)線程在服務(wù)啊
北京-喜(-) 10:56:35
2的話 可能是慢查詢引起的，需要查看DB整體負(fù)載情況、數(shù)據(jù)量、引擎、索引等。3的話，需要對(duì)下游調(diào)用加超時(shí)控制和對(duì)應(yīng)的兜底處理, 4同2.
上海-coty(-) 10:57:00
cpu沒上去可以繼續(xù)加線程啊
上海-大文(-) 10:57:41
CPU占用率比較低
北京-EP查水表(-) 10:58:31
壓測還有一種典型結(jié)果就是，客戶端機(jī)負(fù)載滿了，然后說服務(wù)端的壓測結(jié)果不理想
上海-大文(-) 10:59:09
我是本地自測接口, rpc和數(shù)據(jù)庫都是遠(yuǎn)程服務(wù)
上海-大文(-) 11:01:18
@北京-喜 應(yīng)該不是慢查詢，就一個(gè)id查詢
北京-喜(-) 11:01:54
是個(gè)分段的事情, 你1個(gè)段1個(gè)段去分析 優(yōu)化, 優(yōu)化完一個(gè)點(diǎn)，重新再壓，觀察效果提升度, 然后重復(fù)上面的過程
上海-大文(-) 11:03:09
連接池問題我調(diào)大了，沒有明顯提升
成都-梅小西(-) 11:04:17
你這壓測有很多insert？
上海-大文(-) 11:04:36
一個(gè)，最后一步會(huì)進(jìn)行, 但是并發(fā)量很大, 可能會(huì)影響其他線程
北京-EP查水表(-) 11:04:51
1000/50*70=1400，囧 50ms時(shí)間算出來的一點(diǎn)都不靠譜，偏差那么大，一點(diǎn)都不靠譜
成都-梅小西(-) 11:05:23
insert確實(shí)對(duì)壓測有影響吧。并發(fā)insert，而且是一個(gè)表，如果索引太多，確實(shí)影響不小
武漢-java(-) 11:06:21
把索引都去掉 只留主鍵 , 反正你都是根據(jù)id查詢的
上海-大文(-) 11:06:28
rpc的調(diào)用為什么也這么慢？正常8ms就響應(yīng)的慢的時(shí)候會(huì)拖成幾百ms, 這個(gè)可以試試
成都-梅小西(-) 11:07:15
insert會(huì)根據(jù)索引鎖行
上海-中紀(jì)委(-) 11:10:06
有沒有insert前刪除索引，insert後再重新建索引?
廣州-Ryan(-) 11:11:09
你們這個(gè)調(diào)優(yōu)完全靠猜啊。。。
看一下指標(biāo)再下手，比如連接池，不夠，可以看看歷史連接池?cái)?shù)量。
執(zhí)行SQL，可以看看連接db的速度，和執(zhí)行的速度（不過這個(gè)要在客戶端統(tǒng)計(jì)。）
武漢-java(-) 11:12:33
看監(jiān)控 和db日志 。
2. Kafka在極端情況下會(huì)丟消息；我司CTO說Kafka是工業(yè)級(jí)的，不會(huì)丟消息，丟消息是因?yàn)檎`用了。那么，Kafka到底會(huì)不會(huì)丟消息？[杭州-Freedom]
北京-Easy哥(-) 14:44:48
kafka不丟消息 需要幾個(gè)條件 第一 至少異地機(jī)房 第2 寫操作 至少要寫2個(gè)副本成功 第3 這2個(gè)機(jī)房不能是同一網(wǎng)絡(luò)供應(yīng)商 ,第4 這2個(gè)要寫的副本 必須分布異地機(jī)房 ,能做到 不丟 , 剩下的都是扯. 你只有一個(gè)機(jī)房 google的人來了 也不敢跟你說 不丟.
南京-Tracy(-) 14:46:01
異地機(jī)房，kafka是怎么支持的??？
南京-Tracy(-) 14:46:22
節(jié)點(diǎn)分開放到2個(gè)機(jī)房？
天朝-秋天(-) 14:46:39
第3 這2個(gè)機(jī)房不能是同一網(wǎng)絡(luò)供應(yīng)商 , 這個(gè)是為啥呢
北京-Easy哥(-) 14:46:59
還有好多人 用kafka 的寫策略 是只寫主 不丟才怪
深圳-hxj(-) 14:49:24
同一網(wǎng)絡(luò)供應(yīng)商怕一個(gè)網(wǎng)絡(luò)異常, 我們就出現(xiàn)過一次，都是一個(gè)供應(yīng)商的
3, java IO模型的同步異步 阻塞非阻塞真的是好繞啊, 看了那么多 感覺每個(gè)人講的都是自己的邏輯.有沒有大神總結(jié)過這個(gè)？[深圳-鯰魚]
廣州-小護(hù)士<-> 16:59:30
同步異步是程序執(zhí)行順序
阻塞非阻塞是程序執(zhí)行等待不等待
同步保證執(zhí)行順序，異步不保證
