很對不起大家，又是一篇亂序的文章，但是滿滿的干貨，來源於實踐，相信大家會有所收獲。里面穿插一些感悟和生活故事，可以忽略不看。不過聽大家普遍的反饋說這是其中最喜歡看的部分，好吧，就當學習之后輕松一下。
Redis各種數據結構性能數據對比
測試工具：perf4j
性能指標：平均值，最小值，最大值，方差
對比將814條數據按單條插入到哈希MAP和哈希SET：
對比從814條數據的哈希MAP和哈希SET中判斷一個元素是否存在(map的hasKey和set的isMember)：
大量數據插入哈希MAP，運行一個多小時插入到2w多條的時候再也插入不進去了。想單個刪除也很慢，跟插入差不多的慢。但是刪除一整個key卻很快。這和C語言的原理有關。刪除key其實是刪除的對value的引用，內存空間不需要重置，只在需要的時候將其重寫。寫過一個C語言基礎入門的程序：
#include<stdio.h>
main(){
int a[5]={1,2,3,4,5};
int b[5]={1,2,3};
int c[]={1,2,3,4,5};
static int d[5];
int e[5];
int f[0];
int i;
for(i=0;i<5;i++)printf("%10d",a[i]);printf("\n");
for(i=0;i<5;i++)printf("%10d",b[i]);printf("\n");
for(i=0;i<5;i++)printf("%10d",c[i]);printf("\n");
for(i=0;i<5;i++)printf("%10d",d[i]);printf("\n");
for(i=0;i<5;i++)printf("%10d",e[i]);printf("\n");
for(i=0;i<5;i++)printf("%10d",f[i]);printf("\n");
}
運行結果：
最后兩行出現這個結果的原因是分配的地址空間原來是什么值就會顯示什么值，所以是隨機的。
性能優化實踐
前段時間我改了並發量最大的媒資接口的JVM啟動參數，修改之前棧空間是4G，新生代是1G，基本沒有full gc。minor gc相當頻繁，平時1秒1次，並發量上去之后每秒4,5次。我將棧空間設置為8G，新生代設置為5G，平時大概4,5秒一次，估計並發量上去之后還是會達到1秒1次。當然有的機器會少些。因為我們公司用的是SLB的7層負載均衡，采取的是輪詢策略，負載不是很均勻。我現在在試圖從根本上解決問題，找到minor gc頻繁的原因，最終要將minor gc口平時控制在12秒一次以上。12秒這個數據是怎么來的呢。
看我標出來的這兩個差值，大體新生代的垃圾回收時間是18ms。如果12m一次，就是12000ms中垃圾回收時間占18m，千分之1.5的時間用於垃圾回收，這個比率對於整體性能的影響就沒那么大了。當然各個數組會隨調整變化，到時候要看情況。
之前我也參與過這個媒資接口的性能優化，一直沒有成效是因為第一我對媒資接口不熟，我也不是最主要的負責人，很多事情做不了主。其實，一般解決這個問題的方式是橫向擴展，其實我們有很多空余設備，德偉不肯試試，我也沒辦法。另外，媒資接口雖然是我們這邊最重要的接口了，但是我總會被臨時調到一些更緊急的項目中去，東一點西一點的。雖說覺得自己是個SMP（對稱多核處理器），但是內核上下文切換也得保存現場吧，開銷很大，做不深入，時間片又到了。這都是自己當初沒有想好，沒有自己的負責區域，所以會被來回調。所以現在就做兩件事情。如今設備復用先不考慮了，先從根本上改善程序。
我做了一晚上的測試，凌晨4點才睡。得出來一個結論：我們的定時加載本地緩存對性能有影響。第二天我在地鐵上就發消息到群里說找到性能上不去的根了。第二天我們開會討論了，大家最后的決定是我的想法可以試一試。但是從統計圖表上看，內存，CPU，499和響應時間關聯不大。我說我們系統目前的現狀也不會是一個原因造成的，定時加載本地緩存確實和內存定期的峰值很匹配，確實是問題。既然是問題，就要一點點解決。先拋開問題不談，發現自己的另一個問題：話說的太直，太滿。
之前發生了一件事，我好好反省了一下，很多方面。
有次照例中午和部門里一個小姑娘吃飯。她讓我給她提提建議，怎樣能去阿里。她說你看我人還挺可愛的，能不能靠點別的去阿里。我人實在是太直了，我就向她闡述了確實如果實力不夠是去不了的。越聊到最后發現她並不是在問我的意見，只是想讓我帶她去阿里。我發現這個還是按照自己的思路說下去。結果人家小姑娘氣的一下午沒搭理我。確實我話說的太直太滿，是我要解決的問題。也確實我認為只有實力到了才能去也只是我的想法，人家有人家的方法，只是我不知道，而且不願意用而已。我總認為達到一個目標過程更重要，其實哪是人人都這么想的。思維不夠開放。我經常給別的公司推薦人才，如果覺得這個人實力不夠，我都不會給推。這倒沒有錯，但是對別人應該有更多的鼓勵，遇到委婉的人說話要更委婉一點。
這個小姑娘聊天中提到你看我雖然有些問題自己解決不了，但是我可以找別人解決啊，最終問題都解決了。她是覺得自己是可以干活的，那么去阿里是沒問題的。其實據我了解，阿里不招這種要不要無所謂的。雖然我也沒進阿里，我是這么想的。這個小姑娘雖然沒去阿里，但是去的公司也都可以。但把這個歸因於自己很可愛，很招人喜歡我有點不贊同。物有本末，事有始終。反思一下我自己，記得11年，換工作形式一片大好的時候，我雖然沒有換工作，確實出去面過試。面試其實問題回答的都不是很好，但是都給了offer。其中面了華為的，面試官說咱倆一個學校的，咱們東大的人基礎不應該這么差啊。結果什么都不會，還是要我了。究其原因，要我是因為學校比較好，然后去的公司都比較好，人不笨，覺得還是有培養價值的，反正成本也不是很高。和可不可愛關系不是很大，額，我說話是不是又太直了。其實我當初如果遇到了更多的挫折，現在技術能力應該好不少。所以現在我很珍惜遇到的問題，時間許可的范圍內，解決不好過程，不去追求結果。特別是做技術的，長遠穩定性，前瞻性，很重要。還有一點，女孩子其實在技術工作中面對的劣勢遠遠大於優勢，我自然也遇到過，但是我自己不太清楚是哪些。因為這個劣勢體現在根本不會給我面試的機會。能讓我面試的，我相信面試的過程還是很公平公正的。至少我經歷過的過與不過都有理有據。
我聲稱自己是個技術吃貨，也就是這半年的事情。之前，一直是個技術二貨。上家公司在五道口清華科技園，是朋友在那邊，把我挖過去的。去的時候我就很明確的說因為這邊不是很忙，我家孩子小，我要先照顧好家。分清當前事情的主次是必要的。可是記得那時候每天11點就去吃飯了，吃完飯還要去買個肯德基套餐帶着去旁邊清華大學，到下午3點再回去上班。很多該做的沒做，該學的沒學。當初的時間利用起來，現在不至於這么時不時不由自主的來一句：I am so stupid. 發現身邊很多做技術的女孩子，包括自己在內，對技術現狀，對各大公司的形勢，各個方面攝取的信息太少。不知者無畏，反而會比較自大。前段時間自己也是很浮躁，其實技術基礎都不是很扎實。我有個學弟，工作三年的時候就出去創業做CTO了。旁邊也有很多人很年輕有為的，很早就不做技術了，直接轉管理。我原來在想：我和他們走的路都不一樣。我要盡量更多的時間活躍在底層一線，因為想要工作到60歲。提升的過早，以后會越早達到瓶頸。想法很符合自身的情況，但是實際上努力不夠。行遠自邇，登高自卑。時刻保持危機感，強化學習意識。
回到最初的問題。定時加載本地緩存。我試過，對這個服務來說，已加載在本地緩存的數據獲取速度比遠程（其實這里測試集中緩存和數據庫速度差不多）快幾十倍，而且很穩定。但是最初加載的時候，我們設定啟動后50秒暴露服務，也還是不能保證加載完，會導致服務重啟發生短暫的連接池溢出。而且我感覺我們的dubbo連接池設置了700,太大了，反而導致響應慢。開會討論將緩存全量更新時間由本來的一小時或者半小時設置為12小時試試結果。結果由於發生了一些非技術原因現在正式環境還沒有試，測試環境沒有對比。但是開頭介紹的redis緩存完全可以派上用場。在key值1000個以下的小本地緩存可以第一次加載的時候從redis緩存里取，redis緩存由單獨的后台服務控制更新，記錄最后更新時間。其實更新服務我放到離線服務里了。如果最后更新時間發生變化才會再次取最新數據。我觀察了一個星期，字典值，TV值，字典配置值一個星期就沒變過。耗費那么大的性能去更新，好心疼。然后20幾萬占100M多棧內存的明星數據，定時全量和增量執行更新，啟動都需要幾十秒做這個事情，當初寫這個代碼的哥哥，你寫的時候真的測試過這么做可以提高性能嗎[汗]
epiphany框架改進
既然我要寫文，就不得不提一下我的開源框架進展。這是一個離線數據推送的框架，支持全量，增量和手動發送。幾個部分可分開和整合部署。用戶可以靈活的選取全部部署，或者部分部署。或者在需要的情況下進行升級，降級處理。目前最新版本的改進是支持全量模式耗時長的數據優先運行的策略，以達到總體數據各個線程間耗時平均。當然用戶可以自己決定是否使用此策略。在全量增量同時運行的情況下，支持both模式和yield模式。both模式即運行全量的情況下也運行增量，yield模式即全量運行時增量暫停，待全量運行完接暫停時間點繼續運行。詳情請參閱我的github代碼：https://github.com/xiexiaojing/epiphany
我在寫框架的時候，必定用到很多測試和性能監控的東西。其中JVM我打開了很多參數，發出來供大家參考，紅框標出的是一些監控，測試時可以打開。
程序在跑，今晚夠嗆能睡覺。
生活點滴
前段時間坐公交車，上來一個2歲左右的小朋友，上車一會兒后開始哭，聲音特別大。我猶豫了一下，翻翻包，找到之前包上掉下的一個裝飾，因為還挺好看的，我順手就裝包里了。我拿到小朋友的面前，讓他猜猜這個飾品的兩面是不是一樣的。他不哭了，也不回答，愣愣的看着我。我就把飾品遞到他手上，回到自己的位子。小朋友沒有再哭。下車之后，小朋友在車窗那邊跟我打了好幾個飛吻，這招我兒子就不會。當初猶豫了一會兒是在想萬一哄了還哭，一車人看着我多尷尬。但是想想別把自己當回事，大家誰有閑心看我。事實證明我錯了，我看到全車人都在看我。但是想做什么就去做吧，做了就不后悔了。
男神說我長的難看
全世界我就認識一個當面說我長的難看的，就是我家男神。覺得我應該跟他離婚。不過想想就他嫌我難看，我當初還非要嫁他，看來我倆眼神兒都不咋地，不是一家人不進一家門，還是將就過吧。
看看人家都怎么評價我的：
再看我家男神：
我和男神這幾年來就吵過一次架，就是他說我長的難看。我生氣了，他看我生氣他也生氣了。摔了好幾瓶紅酒然后摔出門去回北京了。兩個小時后他打電話回來說快到公司出差給租的房子那里了，讓我別被玻璃碎片扎到。又過半小時打電話回來說已經開始往回返了。好吧，第二天他又2個多小時回到租的房子附近上班。然后我上班中午吃飯時跟女同事說我家男神說我長的難看。女同事是這么安慰我的：你就跟他說我長的好看還跟你啊，你長的好看啊。我在想在別的情況下我是不是該跟我女同事翻臉，竟敢說我家男神不好看。但是人家是好心，我也就只能低頭喝粥。粥好涼好涼，心拔拔涼。
一家人相處
我們家相處大家很自由。比如說我要是這段時間注重打扮，男神就會向我指出我哪里穿的不好看。如果我這段時間頭也不梳，那就這樣吧，也沒人管，也沒人說。我對我家男神也是，他喜歡干什么工作就什么工作，他說他想早退休我覺得也很正常。我也就默默的想想怎么解決他退休金不夠花的問題。我和婆婆關系相處的特別好。首先一點，我婆婆家樓房是我們有孩子了，但是自己還沒買房子的時候先給他們買的。我家嫁女兒沒要人家一分錢還倒賠了嫁妝。我家兩套房子首付是我出的，貸款我還更多的那套。我也不傻，之所以這么做，老人都窮過，比較看重物質。所以我付出這么多，我心里是平衡的，老人也不會對兒媳太挑剔了。然后婆婆做飯我也從來不挑，好吃就多吃點不好吃就少吃點。孩子大了，婆婆平時沒事兒喜歡撿瓶子賣錢，我也沒意見，各人有各人的想法，開心就好。但是我自己喝的礦泉水瓶子都會拿回家。這是一種尊重。然后婆婆留長發，她用的扎頭繩總是松，所以我要是出門，必然給婆婆買個素色頭繩。謝天謝地，現在的東西都是看着好看不耐用，否則我就少了一個表現的機會。