Redis的相關(guān)知識點和需要注意的問題我們都已經(jīng)梳理過了，關(guān)鍵還是需要運用到實際的工作中才能達到學以致用男杈，下面我們將整理一個實際應用的場景，并且集合Redis來實現(xiàn)其需求景醇。
目前公司有十萬員工欲侮，分成500個部門崭闲，公司為員工制定了每日9點前和18點后網(wǎng)上簽到的制度，簽到之后可以及時查看自身簽到狀態(tài)威蕉，主管可以及時收到下屬員工的簽到狀態(tài)刁俭，一整天未簽到的員工自動補充曠工
以上為場景；請用java+redis+隊列+mysql實現(xiàn)此功能
分析該需求韧涨，首先10w的員工簽到牍戚，這個涉及到高并發(fā)的場景侮繁，并且主管還需要及時收到下屬員工的簽到狀態(tài)，這個需要異步通知的功能翘魄，并且一整天未簽到的員工自動補充曠工鼎天，這個需要一個定時任務來實現(xiàn)
綜上所述我們?yōu)榱藢崿F(xiàn)其功能最少需要高并發(fā)簽到，異步通知以及定時任務這三個技能暑竟，明白了其所需要使用到的技術(shù)斋射，下面我們來一個個的剖析，并且實現(xiàn)這樣的功能但荤。
高并發(fā)來實現(xiàn)簽到功能
為了實現(xiàn)高并發(fā)罗岖，題目中已經(jīng)給出了我們需要使用redis來實現(xiàn)，這個沒得選腹躁，但是我們還是需要分析下是單機版還是Redis集群來實現(xiàn)這樣的功能桑包。
單機還是集群？
10w員工纺非，按照二八定律分析來說大概同時有2w的簽到哑了，也就是寫請求（二八定律真乃神定律，在現(xiàn)實生活中隨處可見）烧颖，單機版本的Redis大概能支持10w左右的QPS（這個數(shù)值有波動弱左，主要跟服務器的性能有關(guān)系，內(nèi)存讀寫速度快的炕淮，這個數(shù)值還會更大點）拆火，所以我們這個單機版的Redis就能實現(xiàn)這樣的功能，如果是員工是100w的話涂圆，我們就需要搭建Redis服務集群们镜，最好還是能做到讀寫分離，這樣還能做到橫向擴容润歉。
數(shù)據(jù)結(jié)構(gòu)很重要ＤＯ痢！
一個適用的數(shù)據(jù)結(jié)構(gòu)能優(yōu)化代碼邏輯卡辰，并且減少操作時間復雜度胞皱，優(yōu)化服務響應速率，提升客戶使用度九妈，所以數(shù)據(jù)結(jié)構(gòu)十分的重要反砌。
- 首先確定使用redis的數(shù)據(jù)類型
學過Java的朋友應該都知道Java中的Map的理想操作時間復雜度是O(1),也就是說對于內(nèi)存來說，訪問任何地址的時間是一樣的萌朱，即時間極短宴树，相當于可以同時訪問到所有地址，那么這里redis的hash數(shù)據(jù)類型和Java的Map是類似的晶疼，所以我們選用hash類型來實現(xiàn)所有員工在Redis中的數(shù)據(jù)存儲
- 繼續(xù)優(yōu)化hash的數(shù)據(jù)結(jié)構(gòu)
看到這里有的朋友可能會考慮酒贬，將10w的員工的信息都存放在Redis中又憨，就需要10w個key(map)，No,No,不是這樣的锭吨！為什么不這樣蠢莺，我們來分析下。
還是跟Map的類型有關(guān),如果10w個map存儲在redis中零如，需要消耗一定的內(nèi)存躏将，并且數(shù)據(jù)越大，內(nèi)存查詢的速度也就越慢考蕾，所以我們的著眼點應該是按照部門來分別存儲祸憋，這樣查詢的時候也可以根據(jù)部門來減少查詢到次數(shù)，所以我們第一層的數(shù)據(jù)結(jié)構(gòu)應該是以部門ID+常量+簽到日期為key的map肖卧，這樣做的好處有兩個：
- 每個人都是歸屬部門的蚯窥，所以先根據(jù)部門來縮小查找的范圍，減少查詢遍歷的次數(shù)：500+2000=2500,也就是說我們定位一個人最大遍歷2500次就夠了塞帐，而如果是直接查詢個人的話拦赠，最大可能遍歷10w次。
- Redis中存放500個map比存放10w個map來的小的多葵姥，減少了redis的數(shù)據(jù)存儲內(nèi)存的消耗
接著矛紫，我們再來分析下value的存儲什么？
我們的需求是員工進行簽到牌里，所以我們的value值中必須要包含是否簽到的相關(guān)信息，這里我們還可以擴展下务甥，需求要求是上班前和下班后都進行簽到牡辽，需要區(qū)分簽到的類型，所以我們還可以添加一個常量來進行簽到類型區(qū)分敞临，其次是誰簽到的态辛，說到這里，我想這個數(shù)據(jù)結(jié)構(gòu)已經(jīng)很清晰了挺尿。
是的還是使用hash結(jié)構(gòu)來存放人員的信息奏黑，其中key值最好是人員的id，而value值可以是簽到的狀態(tài)
- 數(shù)據(jù)結(jié)構(gòu)的確定
至此编矾，經(jīng)過我們的分析熟史，我們確定了Redis中簽到的數(shù)據(jù)結(jié)構(gòu),使用Java的數(shù)據(jù)結(jié)構(gòu)來表達：
// 外圍的Key是String類型： 主要存放部門的id+常量+簽到日期
// 外圍的Value是Map類型：主要存放該部門的人員的信息
// 里層的Key是String類型： 主要存放人員的ID
// 里層的key也是String類型（這里也可以修改為List類型）： 主要存放簽到的狀態(tài)
Map<String,Map<String,String>>
業(yè)務流程的實現(xiàn)
- 初始化數(shù)據(jù)
既然簽到的map數(shù)據(jù)結(jié)構(gòu)已經(jīng)確定了，那么我們該怎么來使用這個數(shù)據(jù)結(jié)構(gòu)來實現(xiàn)我們的業(yè)務呢窄俏？
這里提供一個方案蹂匹，我們可以提前將部門的map的數(shù)據(jù)給初始化，有兩個原因：
- 部門和人員的數(shù)據(jù)一般變動不大凹蜈，所以可以先初始化限寞，節(jié)省時間忍啸，到時直接從Redis中取就可以了
- 避免簽到的時候才來生成部門簽到map，主要是為了避免簽到高并發(fā)時履植，造成數(shù)據(jù)覆蓋現(xiàn)象计雌，導致簽到數(shù)據(jù)不正確
這里的部門簽到map（暫時這么稱呼），其有效期應該設(shè)置為永遠玫霎，避免數(shù)據(jù)失效凿滤！
- 簽到
用戶登錄系統(tǒng)后，我們會在redis中生成用戶的基本信息鼠渺，這里主要是用戶的人員ID和所在部門的ID鸭巴。
- 用戶簽到的時候，將個人信息寫入到redis,主要是為了用戶查看其基本信息拦盹，包括簽到的狀態(tài)信息
- 根據(jù)員工ID和部門ID到部門簽到map中獲取人員的相關(guān)信息鹃祖，并且更新簽到狀態(tài)。這里最好添加鎖普舆，防止被其他員工取到產(chǎn)生競態(tài)恬口，等部門簽到map中的個人簽到狀態(tài)更新成功之后，釋放鎖沼侣，并且更新redis中個人信息中的簽到狀態(tài)
- 將簽到相關(guān)信息放入隊列中
上述的簽到流程操作祖能，可以及時的讓用戶查看到自己的簽到情況，即使高并發(fā)的情況下也不影響系統(tǒng)的響應流暢度
- 通知主管
用戶簽到之后蛾洛，就將簽到的信息發(fā)送到隊列养铸，通過隊列來異步通知主管，這里可以使用RabbitMQ來實現(xiàn)消息的發(fā)送通知轧膘，主要是考慮RabbitMQ的消息的安全和消息消費失敗后钞螟，可以使用死信隊列來實現(xiàn)重發(fā)，確保消息的準確和安全性谎碍。
- 定時數(shù)據(jù)持久化
開啟一個定時任務鳞滨，將部門簽到map提取出來，然后循環(huán)遍歷蟆淀，將人員簽到的信息持久化到數(shù)據(jù)庫拯啦，對于持久化失敗的數(shù)據(jù)，可以寫入到日志中熔任，展示給相關(guān)人員查看褒链。將一整天都未簽到的人員置為曠工。
數(shù)據(jù)持久化后笋敞，可以刪除當天的部門簽到map碱蒙，同時初始化明天需要用到的部門簽到map
可以是用流程圖展示如下：
[圖片上傳失敗...(image-7d95d9-1561206189155)]
至此，我們的整個業(yè)務流程就很清晰了，對應的代碼實現(xiàn)也就很容易了
總結(jié)
在對人員簽到的分析設(shè)計已經(jīng)結(jié)束了赛惩，不過我們就其中的幾個問題需要討論下
為了實現(xiàn)上述的功能哀墓，redis中最小的key值是多少？
我們上面設(shè)計中 redis中的key是500個喷兼？ 那能不能再次縮小呢篮绰？ 其實是可以的，就是在外面再加一層map季惯，這樣保存到redis中就一個key鍵值了吠各，如果這樣設(shè)計的話，那其實沒有什么意義勉抓，還是需要查找到對應的部門贾漏，再查找到人員，這樣反而增加了一步查詢藕筋，還不如不加纵散，而且如果只有一個key值的話，那么用戶簽到的時候需要加鎖隐圾，就將這個key添加了鎖伍掀，這樣話并發(fā)量就不是很大了，所有的用戶都要等該用戶簽到完成后再進行其拿到暇藏，從業(yè)務角度來看就是將10w員工的簽到串行了蜜笤，我們上面設(shè)計的500個key，對不不同部門的人員簽到是不影響的盐碱，從業(yè)務角度來說把兔，不同部門是可以同時簽到的，而且不影響數(shù)據(jù)瓮顽，提高了效率垛贤。
為什么需要吧簽到的信息發(fā)到員工的信息里，還要保存到部門簽到map中趣倾？
我們上面的設(shè)計中 redis的部門簽到map中已經(jīng)存放了人員的簽到信息，為什么還要在個人信息中存放簽到信息呢某饰？ 主要是為了需求中用戶可以隨時查看自己的簽到狀態(tài)儒恋。
這里有的朋友可能就疑問了，部門簽到map中不是已經(jīng)存在了么黔漂，這里主要是為了人員查看的效率考慮的诫尽，如果存放在部門簽到map中，那么每次查看一次都需要從部門簽到map中提取出來個人信息才能查看炬守，這樣會影響查看效率牧嫉。
如果基于redis實現(xiàn)加鎖和釋放鎖功能，如何考慮其中的鎖釋放問題？
加鎖的功能其實也可以由redis來實現(xiàn)酣藻，我們可以在簽到時曹洽，對這個部門ID+加鎖常量+簽到日期，在redis中新增一個key辽剧，如果同部門的其他用戶也來簽到時送淆，先查看是否存在部門ID+加鎖常量+簽到日期的key，如果存在則循環(huán)等待一段時間再請求怕轿，相當于給當前簽到用戶添加了鎖偷崩，等這個用戶簽到成功后，再刪除這個key撞羽。
上面就是簡單的加鎖的功能阐斜，這樣需要考慮釋放鎖的問題，如果加鎖成功了诀紊，程序在處理業(yè)務時程序異常谒出，沒有正常的釋放鎖，這樣就會造成其他的人員獲取不到鎖渡紫，無法進行業(yè)務操作到推，解決這個問題，我們首先需要考慮不管業(yè)務是否成功惕澎，我們都需要釋放鎖莉测，這樣至少不會對其他的人員簽到造成影響。
那么該如何實現(xiàn)這樣能唧喉，其實redis能很簡單的實現(xiàn)捣卤，就是給這個key添加失效時間，這樣只要到失效時間八孝，這個key就會被刪除董朝，也就相當于釋放了鎖。
