本來昨天就打算寫這篇了，但是熬到忘了，至於為什麼要寫這個是因為我昨天在寫 redis 的時候突然想到的
注：此篇文章並沒有講解 redis 內部的使用 或 如何使用redis寫**，等等。。僅僅只是突然想到的，如果各位大佬有什麼想說的，有什麼想補充的，再或者我說的有什麼不對的，請不要客氣，直接講出來，我會非常認真的看的
正片開始...
當時想的是，如果乙個使用者在乙個**系統點選了乙個商品新增購物車，並點選自己的購物車，然後購物車展示已新增的商品，這都可以放到redis，看似好像沒什麼問題，但是我就突然想到，如果這個使用者在很早之前就新增了一件商品，而很久之後的今天，點選了自己的購物車，首先 redis 中並沒有儲存他之前購買的商品( 假設這個時間段中 redis 已經將資料更新到資料庫中 )，這個時候，如何將商品展示呢，我想著，這不還是得去資料庫(mysql)查嗎，既然還是要去資料庫查，那為什麼還要多 redis 這一步呢，當時，因為這個問題想了很久，實在想不到什麼，然後去各個地方去問，雖然並找不到人討論( 還是很難受的。。)，但是，一會後關於這個問題我又想到一點，首先，第一次訪問，展示購物車商品肯定要去資料庫查詢的，如果在訪問購物車之前使用者已經新增了一件商品，那麼將這個商品儲存在 redis 中（以使用者唯一id為key）的話，那麼是不是可以減少一次資料庫的查詢呢？ 你看啊，使用者第一次訪問這個**，看到一件商品，然後加入購物車( 此時將這件商品儲存在 redis 不直接儲存在資料庫 )，然後使用者點選自己的購物車的時候，就不需要去資料查詢剛剛新增的商品了，直接去 redis 中查就行了，但是還是要去資料庫查詢當前使用者購物車中其他商品的資料的，但是，但是，這樣可以減少一次在資料庫中的查詢和儲存啊，因為新增購物車後，並沒有直接更新到資料庫，而是儲存在 redis 中了，所以資料庫只需要查詢他其他的購物資料，剛剛新增的那條資料就不用在資料庫查詢了，直接從 redis 查詢就行了，雖然這看似在資料庫中可以少查一條資料，但是，如果乙個**的訪問量特別大呢？比如同時有十萬次的新增購物車商品的資料，是不是需要在資料庫插入十萬條資料，這還不算完，如果都點選了購物車展示頁面，那麼是不是還要除了查詢當前使用者其他的購物車商品資訊外，還需再多十萬次的資料庫查詢？如果儲存再 redis 中的話，首先資料庫查詢當前使用者的其他購物車商品資訊，然後再去redis 中查詢剛剛的儲存的十萬條資訊就行了，這樣資料庫就減少了十萬次的資料更新和查詢，最後寫乙個指令碼，等到某乙個時間段將 redis 更新到資料的操作就行了。
使用 redis 的主要原因是因為它是儲存在記憶體的，所以查詢速度非常快的，雖然有時候儲存幾條資料看上去並沒有什麼影響，但是一旦量巨大的話，其作用還是非常大的
再說一下適用場景：
1. 乙個頁面中某個資料的頻繁操作，比如乙個商品有不同的****，那麼每次點選不同的**就是一次資料更改，所以可用 redis 儲存
2. 每次需要請求大量的資料，而且這些資料過一段時間後可能就沒什麼太大的作用，等等。。
3.額。。其實我也想不到什麼了，目前想法有限制，所以歡迎來補充，我也會持續更新這一篇的，雖然可能會很久，如果我以後工作遇到這方面問題，一定會更新
關於我之後的想法
突然有個很奇怪的想法
沒有嚴密論證,算是假說吧 先說乙個當年否決地球是宇宙中心的故事,我對人名不太上心,簡單說就是火星的軌道逆走,天文上有個術語叫視逆行.就是火星的軌跡在天空中某個時候會 往後走 一段距離然後繼續前行.即如果地球是宇宙的中心,所有的天體繞著地球轉,那麼是誰有那麼大力氣把火星往後拉再往前推,而且無聊到定期去...
關於創業的想法
想創業，不要總想著做出什麼驚天地的尖端產品，首先要看誰有困難需要你利用技術手段來幫助他克服，然後是利用最低端的技術去解決他們的困難從而保證你的產品質量，盡量讓人家 少付出代價 這樣搞你才有 白手起家 的可能，否則你就去找 賺 第一桶風險金，再努力撐到出產品，再撐到找著客戶，然後拼命留住回頭客再爭到新...
關於封裝的想法
從自己做自己的開發架構以來，逐漸理解封裝的含義和帶來的好處。1 三年來，自己的架構從滿足簡單的查詢列表配置，到現在複雜的列表 詳述 列印以及複雜的編輯頁面的配置，始終堅持框架的無業務性，框架就是提供業務應用的架構。2 封裝的另乙個對自己覺得最大的好處是修改和擴充套件，只需要在該修改和擴充套件的地方修...