jtea

摘要： # 前言 本篇來(lái)介紹一下redis pipeline，主要是由于最近一次在幫開(kāi)發(fā)同學(xué)review代碼的時(shí)候，發(fā)現(xiàn)對(duì)redis有個(gè)循環(huán)操作可以?xún)?yōu)化。場(chǎng)景大概是這樣的，根據(jù)某個(gè)uid要從redis查詢(xún)一批數(shù)據(jù)，每次大概1000個(gè)key左右，如果查得到就返回，否則查db，然后寫(xiě)回緩存。由于每次要查的key 閱讀全文

摘要： # 前言 在面試這一篇我們介紹過(guò)[CountDownLatch和CyclicBarrier](https://github.com/jmilktea/jtea/blob/master/%E9%9D%A2%E8%AF%95/CountDownLatch%E5%92%8CCyclicBarrier.md 閱讀全文

摘要： ## 背景 生產(chǎn)上有個(gè)導(dǎo)報(bào)表功能，工作了很長(zhǎng)一段時(shí)間一直都很穩(wěn)，沒(méi)出現(xiàn)過(guò)什么問(wèn)題，最近運(yùn)營(yíng)同學(xué)突然反饋導(dǎo)出來(lái)的數(shù)據(jù)和實(shí)際的對(duì)不上，經(jīng)過(guò)排查發(fā)現(xiàn)導(dǎo)出的數(shù)據(jù)有重復(fù)，也有的沒(méi)導(dǎo)出來(lái)。 由于我們提前生成好數(shù)據(jù)（每天會(huì)truncate重新生成），所以導(dǎo)出的邏輯非常簡(jiǎn)單，不需要關(guān)聯(lián)很多表?yè)茢?shù)據(jù)，只需要從一張表查 閱讀全文

摘要： 要解決多線(xiàn)程并發(fā)問(wèn)題，常見(jiàn)的手段無(wú)非就幾種。加鎖，如使用synchronized,ReentrantLock，加鎖可以限制資源只能被一個(gè)線(xiàn)程訪(fǎng)問(wèn)；CAS機(jī)制，如AtomicInterger,AtomicBoolean等原子類(lèi)，通過(guò)自旋的方式來(lái)嘗試修改資源；還有本次我們要介紹的ThreadLocal類(lèi) 閱讀全文

摘要： # 前言 為了更好的進(jìn)行開(kāi)發(fā)和維護(hù)，我們都會(huì)對(duì)程序進(jìn)行分層設(shè)計(jì)，例如常見(jiàn)的三層，四層，每層各司其職，相互配合。也隨著分層，出現(xiàn)了VO，BO，PO，DTO，每層都會(huì)處理自己的數(shù)據(jù)對(duì)象，然后向上傳遞，這就避免不了經(jīng)常要將一個(gè)對(duì)象的屬性拷貝給另一個(gè)對(duì)象。 例如我有一個(gè)User對(duì)象和一個(gè)UserVO對(duì)象，要 閱讀全文

摘要： ## 問(wèn)題描述 分享一個(gè)發(fā)版過(guò)程服務(wù)報(bào)錯(cuò)問(wèn)題，問(wèn)題出現(xiàn)在每次發(fā)版，服務(wù)準(zhǔn)備下線(xiàn)的時(shí)候，報(bào)錯(cuò)的位置是在將任務(wù)submit提交給線(xiàn)程池，使用Future.get()引發(fā)的TimeoutException，錯(cuò)誤日志會(huì)打印下面的"error"。偽代碼如下： ``` List>>> futures = new 閱讀全文

摘要： 隨著時(shí)間推移，參與開(kāi)發(fā)的人員越來(lái)越多，項(xiàng)目代碼也會(huì)越來(lái)越復(fù)雜，需要我們有意識(shí)的定期對(duì)代碼進(jìn)行優(yōu)化，有問(wèn)題及時(shí)解決，避免技術(shù)債務(wù)越積越多。 這不本人就遇到一個(gè)服務(wù)啟動(dòng)慢的問(wèn)題，印象中服務(wù)啟動(dòng)是比較快的，一般也就20幾秒，但這次開(kāi)發(fā)一個(gè)需求發(fā)現(xiàn)服務(wù)啟動(dòng)要接近1分鐘，這對(duì)本地開(kāi)發(fā)調(diào)試，測(cè)試同學(xué)測(cè)試都是非常 閱讀全文

摘要： # 前言 現(xiàn)有主流消息中間件都是生產(chǎn)者-消費(fèi)者模型，主要角色都是：Producer -> Broker -> Consumer，上手起來(lái)非常簡(jiǎn)單，但仍有需要知識(shí)點(diǎn)需要我們關(guān)注，才能避免一些錯(cuò)誤的使用情況，或者使用起來(lái)更加高效，例如本篇要講的kafka分區(qū)分配策略。 在開(kāi)始前我們先簡(jiǎn)單回顧一下kafk 閱讀全文

摘要： 簡(jiǎn)介 限流顧名思義是對(duì)流量大小進(jìn)行限制，防止請(qǐng)求數(shù)量超過(guò)系統(tǒng)的負(fù)載能力，導(dǎo)致系統(tǒng)崩潰，起到保護(hù)作用。 現(xiàn)實(shí)生活中限流也隨處可見(jiàn)，節(jié)假日出門(mén)旅行的人數(shù)會(huì)劇增，對(duì)于旅游景點(diǎn)來(lái)說(shuō)往往會(huì)不堪重負(fù)，如果不進(jìn)行人數(shù)控制，對(duì)整個(gè)景點(diǎn)的壓力會(huì)非常大，游客的體驗(yàn)也會(huì)非常差，還容易出現(xiàn)安全事故等危險(xiǎn)。 同樣的在一線(xiàn)城市 閱讀全文

摘要： 前言 "redis是單線(xiàn)程的" 這句話(huà)我們耳熟能詳。但它有一定的前提，redis整個(gè)服務(wù)不可能只用到一個(gè)線(xiàn)程完成所有工作，它還有持久化、key過(guò)期刪除、集群管理等其它模塊，redis會(huì)通過(guò)fork子進(jìn)程或開(kāi)啟額外的線(xiàn)程去處理。所謂的單線(xiàn)程是指從網(wǎng)絡(luò)連接(accept) -> 讀取請(qǐng)求內(nèi)容(read) 閱讀全文