五月天av在线,黄色小视频在线免费,久久电影三级无码,日韩三级国产,人人干人人的,黑人巨大开小嫩苞,韩日无码电影,久久久久久国产精品频道

你好呀，我是歪歪。

是這樣的，前幾天我收到掘金的系統(tǒng)通知說我在活動(dòng)中中獎(jiǎng)了。

然后我點(diǎn)進(jìn)去一看，好家伙榮登榜眼：

是我之前寫的這篇文章：《面試官：要不我們聊一下“心跳”的設(shè)計(jì)？》

但是這不重要，重要的是我看一下第一名寫的文章，有點(diǎn)東西，又學(xué)到一個(gè)問題的解決方案，所以我想分享一下。

文章地址在這里：

https://juejin.cn/post/7041076758711369764

高并發(fā) PV 問題

他的文章標(biāo)題是這樣的：

首先他給出了一個(gè)業(yè)務(wù)場(chǎng)景：在一些需要統(tǒng)計(jì) PV(Page View), 即頁(yè)面瀏覽量或點(diǎn)擊量高并發(fā)系統(tǒng)中，如：知乎文章瀏覽量，淘寶商品頁(yè)瀏覽量等，需要統(tǒng)計(jì)相應(yīng)數(shù)據(jù)做分析。

比如我的公眾號(hào)閱讀量大概在 3000 左右，如果要統(tǒng)計(jì)我這種小號(hào)主的 PV 其實(shí)就很簡(jiǎn)單，就用 Redis 的 incr 命令輕輕松松就實(shí)現(xiàn)了。

但是，假設(shè)微信公眾號(hào)每天要統(tǒng)計(jì) 10 萬篇文章，每篇文章的訪問量 10 萬，如果采用 Redis 的 incr命令來實(shí)現(xiàn)計(jì)數(shù)器的話，每天 Redis=100 億次的寫操作，按照每天高峰 12 小時(shí)來算，那么 Redis 大約 QPS=57萬。

如此大的并發(fā)量，CPU 肯定滿負(fù)載運(yùn)行，網(wǎng)絡(luò)資源消耗也巨大，所以直接使用 incr 命令這種技術(shù)方案是行不通的。

假設(shè)這是一個(gè)面試場(chǎng)景題，你會(huì)怎么去回答呢？

其實(shí)你也別想的有多復(fù)雜，剝離開場(chǎng)景，這無外乎就是一個(gè)高并發(fā)的問題。

而高并發(fā)問題的解決方案，基本上逃不過這三板斧：緩存、拆分、加錢。

所以這個(gè)老哥給出的方案就是：緩存。

二級(jí)緩存

Redis 都已經(jīng)是緩存了，那么再加緩存算什么回事呢？

那就算是二級(jí)緩存了。

而且這個(gè)緩存，就在 JVM 內(nèi)存里面，比 Redis 還快。

其核心思想是減少 Redis 的訪問量。這些理論的東西，大家應(yīng)該都知道。

那么通過什么方案去減少 Redis 的訪問量呢，這個(gè)二級(jí)緩存應(yīng)該怎么去設(shè)計(jì)呢？

首先，文章服務(wù)采用了集群部署，在線上可以部署多臺(tái)。

然后每個(gè)文章服務(wù)，增加一級(jí) JVM 緩存，即用 Map 存儲(chǔ)在 JVM，key 為當(dāng)前請(qǐng)求所屬的時(shí)間塊。

就是這個(gè)意思：

Map> = Map<時(shí)間塊，Map<文章id,訪問量>>

但是我覺得巧妙的地方在于這里提到的“時(shí)間塊”的概念。

什么是時(shí)間塊?

就是把時(shí)間切割為一塊塊，例如：一篇文章在1小時(shí)，30分鐘、5分鐘的時(shí)間內(nèi)產(chǎn)生了多少閱讀量。

如何切割時(shí)間塊呢？

這里利用到了時(shí)間是不斷增長(zhǎng)的特性。

時(shí)間戳是自 1970 年1月1日（00:00:00 GMT）至當(dāng)前時(shí)間的總數(shù)，通過確定時(shí)間塊大小，算出當(dāng)前請(qǐng)求所屬的時(shí)間戳從 1970 年算起位于第幾個(gè)時(shí)間塊，這個(gè)算出來的第幾個(gè)時(shí)間塊就是小時(shí) key ，即 map 的 key。

舉個(gè)例子：

我們把時(shí)間按照“小時(shí)”的維度進(jìn)行劃分。

先把當(dāng)前的時(shí)間轉(zhuǎn)換為為毫秒的時(shí)間戳，然后除以一小時(shí)，即當(dāng)前時(shí)間 T/1000*60*60=小時(shí)key，然后用這個(gè)小時(shí)序號(hào)作為key。

比如：

2021-12-26 15:00:00 = 1640502000000毫秒

那么小時(shí)key= 1640502000000/1000*60*60=455695，即是距離 1970 年開始算的第 455695 個(gè)時(shí)間塊。

2021-12-26 15:10:00 = 1640502600000毫秒，那么算出來的 key =455695.1，向下取整，key 還是等于 455695。

意思是這段時(shí)間的時(shí)間塊是一樣的，所以統(tǒng)計(jì)到 JVM 內(nèi)存中的 Map 的時(shí)候，對(duì)應(yīng)的 key 是一樣的。

畫個(gè)圖示意一下：

上圖中，在 2021-12-25?15:00:00 到?2021-12-25?15:59:59 時(shí)間段內(nèi)產(chǎn)生的閱讀量都會(huì)映射到 Map 的 key= 455695 的位置去。

在?2021-12-25?16:00:00?到?2021-12-25?16:59:59 時(shí)間段內(nèi)產(chǎn)生的閱讀量都會(huì)映射到 Map 的 key= 455696 的位置去。

以此類推，每一次PV操作時(shí)，先計(jì)算當(dāng)前時(shí)間是那個(gè)時(shí)間塊，然后存儲(chǔ)Map中。

整體方案

當(dāng)我們把數(shù)據(jù)緩存到內(nèi)存中之后，就極大的減少了對(duì)于 Redis 的訪問。

但是我們還是得把數(shù)據(jù)同步到 Redis 里面去，因?yàn)樵L問文章數(shù)據(jù)的時(shí)候還是得從 Redis 中獲取數(shù)據(jù)。

所以，這里就涉及到一個(gè)問題：什么時(shí)候、怎么把數(shù)據(jù)同步到 Redis 呢？

看一下作者給出的方案設(shè)計(jì)：

整體流程還是比較清楚，主要說一下里面的兩個(gè)定時(shí)任務(wù)。

其中一級(jí)緩存定時(shí)器的邏輯是這樣的：假設(shè)每 5 分鐘（可以根據(jù)需求調(diào)整）從 JVM 的 Map 里面把時(shí)間塊的閱讀 PV 讀取出來，然后 push 到 Redis 的 list 數(shù)據(jù)結(jié)構(gòu)中。

list 存儲(chǔ)的數(shù)據(jù)為 Map<文章Id，訪問量PV>，即每個(gè)時(shí)間塊的 PV 數(shù)據(jù)。

另外一個(gè)二級(jí)緩存定時(shí)器的邏輯是這樣的：每 6 分鐘（需要比一級(jí)緩存的時(shí)間長(zhǎng)），從 Redis 的 list 數(shù)據(jù)結(jié)構(gòu)中 pop 出數(shù)據(jù)，即Map<文章Id，訪問量PV>。

然后把對(duì)應(yīng)的數(shù)據(jù)同步到 DB 和 Redis 中。

代碼實(shí)戰(zhàn)

代碼主要分為四個(gè)步驟，我也把代碼粘過來給大家看看。

步驟1：PV請(qǐng)求處理邏輯

//保存時(shí)間塊和pv數(shù)據(jù)的map
public??static?final??Map>?PV_MAP=new?ConcurrentHashMap();

/**
?* pv請(qǐng)求調(diào)用：
?*?即當(dāng)前時(shí)間T/1000*60*60=小時(shí)key，然后用這個(gè)小時(shí)序號(hào)作為key。
?*?例如：
?*?2021-11-09?15:30:00?=?1636443000000毫秒?
?*?小時(shí)key=1636443000000/1000\*60\*60=454567.5=454567
?*
?*?每一次PV操作時(shí)，先計(jì)算當(dāng)前時(shí)間是那個(gè)時(shí)間塊，然后存儲(chǔ)Map中。
?*?@param?id?文章id
?*/
public?void?addPV(Integer?id)?{
????//生成環(huán)境：時(shí)間塊為5分鐘
????//為了方便測(cè)試?改為1分鐘?時(shí)間塊
????int?timer=1;
????long?m1=System.currentTimeMillis()/(1000*60*timer);
????//拿出這個(gè)時(shí)間塊的所有文章數(shù)據(jù)
????Map?mMap=Constants.PV_MAP.get(m1);
????if?(CollectionUtils.isEmpty(mMap)){
????????mMap=new?ConcurrentHashMap();
????????mMap.put(id,new?Integer(1));
????????//<1分鐘的時(shí)間塊，Map<文章Id,訪問量>>
????????Constants.PV_MAP.put(m1,?mMap);
????}else?{
????????//通過文章id?取出瀏覽量
????????Integer?value=mMap.get(id);
????????if?(value==null){
????????????mMap.put(id,new?Integer(1));
????????}else{
????????????mMap.put(id,value+1);
????????}
????}
}

步驟2：一級(jí)緩存定時(shí)器消費(fèi)

定時(shí)（5分鐘)從 JVM 的 ?Map 把時(shí)間塊的閱讀 PV 取出來，然后 push 到 Reids 的 list 數(shù)據(jù)結(jié)構(gòu)中，list 的存儲(chǔ)的數(shù)據(jù)為 Map<文章id，訪問量PV> 即每個(gè)時(shí)間塊的 PV 數(shù)據(jù)

/**
?*?一級(jí)緩存定時(shí)器消費(fèi)調(diào)用方法：
?*?定時(shí)器，定時(shí)（5分鐘）從jvm的map把時(shí)間塊的閱讀pv取出來，
?*?然后push到reids的list數(shù)據(jù)結(jié)構(gòu)中，list的存儲(chǔ)的書為Map<文章id，訪問量PV>即每個(gè)時(shí)間塊的pv數(shù)據(jù)
?*/
public?void?consumePV(){
????//為了方便測(cè)試?改為1分鐘?時(shí)間塊
????long?m1=System.currentTimeMillis()/(1000*60*1);
????Iterator?iterator=?Constants.PV_MAP.keySet().iterator();
????while?(iterator.hasNext()){
????????//取出map的時(shí)間塊
????????Long?key=iterator.next();
????????//小于當(dāng)前的分鐘時(shí)間塊key?，就消費(fèi)
????????if?(key????????????//先push
????????????Map?map=Constants.PV_MAP.get(key);
????????????//push到reids的list數(shù)據(jù)結(jié)構(gòu)中，list的存儲(chǔ)的書為Map<文章id，訪問量PV>即每個(gè)時(shí)間塊的pv數(shù)據(jù)
????????????this.redisTemplate.opsForList().leftPush(Constants.CACHE_PV_LIST,map);
????????????//后remove
????????????Constants.PV_MAP.remove(key);
????????????log.info("push進(jìn){}",map);
????????}
????}
}

步驟3：二級(jí)緩存定時(shí)器消費(fèi)

定時(shí)(5分鐘)，從 Redis 的 list 數(shù)據(jù)結(jié)構(gòu) pop 彈出 Map<文章id，訪問量PV>，彈出來做了2件事:

先把 Map<文章id，訪問量PV>，保存到數(shù)據(jù)庫(kù)
再把 Map<文章id，訪問量PV>，同步到 Redis 緩存的計(jì)數(shù)器 incr

步驟4：查看瀏覽量

用了一級(jí)緩存，所有的高并發(fā)流量都收集到了本地 JVM，然后 5 分鐘同步給二級(jí)緩存，從而給 Redis 降壓。

@GetMapping(value?=?"/view")
public?String?view(Integer?id)?{
???//文章pv的key
????String?key=?Constants.CACHE_ARTICLE+id;
????//調(diào)用redis的get命令
????String?n=this.stringRedisTemplate.opsForValue().get(key);
????log.info("key={},閱讀量為{}",key,?n);
????return?n;
}