----需求明細:
現有多個角色,角色間需要互動,內容分為申請,審核通過,拒絕,解除合作.每個角色進入自己後台顯示檢視其他角色的未讀訊息個數,點選進入顯示所有傳送來的內容.最開始只儲存未讀個數,並不知道具體的訊息是什麼,是誰傳送過來的,點選進入的時候未讀數量就清空.隨著業務的發展,這種應用已經不適應了,需要進行公升級,所以我就仔細的研究了一下.
開始設計:
因為本專案中有用到redis,而且最初也是用redis 做訊息提醒,所以,最先考慮到的就是公升級redis的使用方法.
為每個角色存乙個set/list型別的key-value,key為自己的id,每次其他角色向自己傳送(申請,解除合作,拒絕)訊息時,就想集合中存如一條資料內容為自己的id+訊息型別,這樣同樣可以同級未讀訊息個數,並且可以檢視訊息內容,是誰傳送的,但是如何做到檢視過了就變成已讀呢?首先想到的就是刪除集合裡面的資料,這種方式有一種侷限性,就是說資訊不能儲存,沒法檢視歷史.沒法記錄時間.
所以,結構就清晰了,即每個角色建立兩個redis集合,乙個是zset,用來儲存每個其他角色發過來訊息內容,乙個是hash型別,記錄最後時間.
TinyURL設計方案
現在貌似tinyurl很火爆，也逐漸成為一種流行趨勢。對應於php版本的tinyurl也有一些演算法，其實本質上來說是一種hash。除此之外，還有另外一種tinyurl方案 類似於http img.ly 其實這種設計 是最簡單的，沒有使用hash，而是遞增，這種的好 處就是資料庫 可以無限擴充套件，...
許可權設計方案
簡要介紹一下該許可權管理系統的特點，該系統功能上做到了靈活授權，操控細緻，許可權可以細到按鈕及超鏈級別,而且部署簡單，下面談談我自己的設計經驗。該系統主要功能如下 1 自定義操作動作 如增加 刪除 修改 審核等，不再是以前見過的那種粗粒度的 按模組分配許可權，或者稍微先進點的規定死某幾個操作了 2 ...
快取設計方案
redis提供的快取的api，但是在開發階段，如果每個人都自己呼叫原生api實現快取時，由於每個人的水平問題，會導致實現方案千差萬別，同事又很難統一管理維護 通過提供spring的annotation，實現快取方案的統一 target retention retentionpolicy.runtim...