摘要： 在分布式系統的數據一致性問題（一）里面，簡單的介紹了分布式數據的同步問題，上面的問題比較抽象，在目前的互聯網應用中還很少見，這次在通過一個比較常見的例子，讓大家更深入的了解一下分布式系統設計中關于數據一致性的問題這次我們拿我們經常使用的功能來考慮吧，最近網購比較熱門，就以京東為例的，我們來看看京東的一個簡單的購物流程用戶在京東上下了一個訂單，發現自己在京東的賬戶里面有余額，然后使用余額支付，支付成功之后，訂單狀態修改為支付成功，然后通知倉庫發貨。假設訂單系統，支付系統，倉庫系統是三個獨立的應用，是獨立部署的，系統之間通過遠程服務調用。訂單的有三個狀態：I:初始 P:已支付 W:已出庫，訂單金額 閱讀全文

摘要： 最近寫了一個關于 鐵道部購票系統的若干文章鐵道部新客票系統的設計（一）鐵道部新客票系統的設計（二）鐵道部新客票系統的設計（三）正好遇到一個博友，咨詢了一個問題，這個問題正好可以作為分布式系統的數據一致性的簡單例子，當然，這個只是比較簡單的情況現在先拋出問題，假設有一個主數據中心在北京M，然后有成都A，上海B兩個地方數據中心，現在的問題是，假設成都上海各自的數據中心有記錄變更，需要先同步到主數據中心，主數據中心更新完成之后，在把最新的數據分發到上海，成都的地方數據中心A，地方數據中心更新數據，保持和主數據中心一致性（數據庫結構完全一致）。數據更新的消息是通過一臺中心的MQ進行轉發。先把問題簡單化 閱讀全文

摘要： 鐵道部新客票系統的設計（一）鐵道部新客票系統的設計（二）鐵道部新客票系統的設計（三）最近只是一時興起，覺得無聊，正好要到買票的時候，寫了這個一系列文章，首先是對自己這些年來的工作經驗的總結，其次是把分布式事務性系統的設計思想進行分析和整理，最后也就是和想集大家的智慧，討論系統的設計。我不是鐵道部的工程師，我只是一家互聯網金融類公司的屌絲工程師，級別不高，能力也一般，就是喜歡技術而已。在第二篇文章里面，重點分析了余票庫的整體設計，我看到有的評論說了幾點，現在整理一下1 為什么要用悲觀鎖為什么要用鎖，由于之前是做金融系統，對數據的一致性要求很高。鐵道部的出票操作要保證數據一致性，所以必須在獲取余票 閱讀全文

摘要： 今天早上坐車的時間正好讀完了這一篇文章《一位資深程序員對當前軟件行業的技術感悟》，覺得有一點意思，可以拿來寫寫作者有15年的IT工作經驗，3年的管理經驗，想想自己，如果算上大學自己兩年做的項目，加上工作6年的經驗，也有8年了作者說：“不過在這同時，給公司內部也做了很多J2EE的項目，例如公司的門戶網站，公司內部的release平臺，以及team內部用的小工具。不過好景不長，從開發就轉向了管理，一管就是3年，在這三年中不夸張的說去趟廁所都是跑著去跑著回，這還不是最杯具的，最杯具的是根本沒有時間寫任何代碼！！！”其實很多人期待從技術轉向管理，技術人員轉讓管理人員最大的挑戰就是會有一種失去安全感的感 閱讀全文

摘要： 鐵道部新客票系統的設計（一）鐵道部新客票系統的設計（二）鐵道部新客票系統的設計（三）在上一篇文章中 鐵道部信客票系統設計（一） 里面，探討了關于數據庫層面的功能性需求以及非功能性的需求，在非功能性需求里面，一博主 提出了沒有考慮到峰值的情況，這一點的確漏掉了，因為我們鐵道部的特殊需求，在春運期間負載很大，平時可能一般，如果用考慮最大的情況，則回存在浪費的情況，如果考慮不足，就像網絡訂票一樣，苦逼。就好比 鐵道部春運的時候，發車量大，但是如果制造大量列車，平時就空閑了，也就很虧。機器的折舊很是塊的。春運期間可以考慮緊急擴容來實現，所以從設計上可以保持這種擴展性。 擴容是一項工程，整體來說比較復雜 閱讀全文

摘要： 從剛畢業到目前所在公司，差不多6年了，想想這六年里面，自己的能力和剛畢業比有了很大的提升，但是現在在什么能力上，我不知道，畢竟沒有去過別的公司。最近也在思考自己未來，算是比較迷茫階段。趁最近比較閑，順便整理一下自己的職業路程剛畢業階段---工作一年半 剛畢業進入公司，公司的規模還算比較小的，那個時候覺得很開心，過的也比較充實，自己的任務就是寫代碼，讀代碼。在那個時候，自己的能力提升的非常快，畢竟在學校里面做的項目完全無法和公司的所在的項目類比。公司有一套自己的框架，在那個時候的我看來，寫的非常不錯。有很多比較好的編程規范：約定大于配置，強制樹狀依賴，多工程模型，但是也存在明顯的問題，就是大量. 閱讀全文

摘要： 鐵道部新客票系統的設計（一）鐵道部新客票系統的設計（二）鐵道部新客票系統的設計（三）這幾天正好看到一條新聞鐵道部:新客票系統2015年建成 ，正好最近想整理和總結一下這幾年的工作中的收獲，正好可以借這個機會，嘗試設計一下鐵路客票系統，把自己所學全部用到這個系統中去，順便也希望各位猿們拍磚，一起探討一下設計，技術嗎，討論討論總是有點收獲的，總比一個人在那里看書好。非功能性要求廢話不說，這里先脫離系統的整體架構，后續在不斷完善整體架構，這里首先討論的是數據庫層面的設計，因為對于整個架構系統來說，數據庫的設計是最為關鍵重要的，數據庫的設計好與壞，決定了整個系統的性能，可用性，擴展性。在考慮數據庫的設 閱讀全文

摘要： 無意中看到程序員雜志中 關于編程的四個境界，覺得非常有意思，也比較有道理，想想自己也是這么過來的1 無意識無能力（不知道自己不知道這個時候是剛開始接觸編程到編程有差不多一年左右的時間，大多數這個時候在大學生涯，年少輕狂，激情四射，學習起來超級有干勁，尤其當自己知道一個個編程法則，寫出很自己認為很牛逼的程序，研究過高深的算法，做過幾個項目，覺得編程很簡單。我當初就是這樣的，在大學的時候會用 spring，hibernate，tapestry（貌似這個不是很流行),struts做過兩個中型項目，學習過設計模式，部署過ejb，看過soa相關的皮毛知識，覺得自己無敵了，都不知道學習什么了，覺得所有框架 閱讀全文

摘要： 想想從大學到現在，也用過很多編程語言，比如C，C++，java，javascript，objective c ，php主要編程語言嗎，當然是java ，由于自己所在的公司是金融互聯網行業，雖然在行業歸屬上算是互聯網行業，但是更偏向軟件行業。間接的會用到javascript和php搗鼓自己的網站，目前在開發ios上面的一些產品，用到objective c。由于自己在所在的公司N久沒有寫過代碼了，寫java代碼的時間也越來越少了，最近重新開始做項目，不知為啥，越來越討厭java語言了。正如《黑客與畫家》里面所描述的，喜歡編程的人的確是不喜歡使用java語言的。為啥，首先java語言的強類型，是靜態 閱讀全文

摘要： 最近和一個朋友在討論職場的上的一些問題，為什么有些人升的非常快，有些人升的比較慢。有些人同事都非常認同，但是領導不認同，有些人領導認同，但是同事卻不認同。在和他聊過之后，有一些事情自己豁然開朗，比較后悔為什么自己沒有早一點明白這個道理。1 職場上最重要的就是積極的心態。領導永遠喜歡的就是積極的人的，也就是我們常說的比較主動。很多人在職場上，會遇到一些挫折，不想干活，有時候在積極主動一小段時間之后，發現沒有結果，就容易放棄。而我的想法就是，要一貫的積極主動。如果你對你自己的工作木有興趣，實在提不起來精神，就果斷的放棄的，找新的環境和事情去挑戰。只有積極主動的人，才能夠取得成功。也是聰明工作的前提 閱讀全文

摘要： 今天給自己的macbook裝上了公司的apple開發者賬號，以前總是用我的機器寫代碼但因為沒有開發者賬號不能給真機裝也不能在真機上測試，想測試還需要把代碼轉移到其他機器上，很不方便，剛在網上找到一些方法裝上了賬號。感覺這個問題還是很普遍的，而且今天就為裝這個也費了不少功夫有很多方法都沒走成，因此把它總結出來，方便更多人能很快裝上~我的情況是這樣的，公司有一個開發者賬號，我個人的機器上沒有裝開發者證書，寫的程序無法在真機上測試，因此我今天的任務就是在已有開發者賬號、證書的基礎上給自己電腦裝上。我之前是用賬號登陸apple developer網站，從網站上下載了公共證書，但最后實驗成功的那個帖子上 閱讀全文

摘要： http://www.cocoachina.com/newbie/basic/2012/0105/3835.html原帖地址：http://www.cocoachina.com/bbs/read.php?tid=59387ElementSize (in points)Window (including status bar)320 x 480 ptsStatus Bar(How to hide the status bar)20 ptsView inside window(visible status bar)320 x 460Navigation Bar44 ptsNav BarImage/ 閱讀全文

摘要： 對知識資產的投資總能獲得最好的回報 -----本杰明-富蘭克林在《程序員修煉知道》里面，提到了知識投資，其實知識投資就是不斷學習，提高自己能力的過程而這個能力，就是知識資產的外在表現形式。對知識資產的投資和金融資產的投資有很多地方其實很像，對于金融投資來說，基本原則如下需要持續的投資，周期性的投資需要找有價值的股票進行投資要控制好風險，一般來說，高風險高收益，低風險低收益。需要自己評估風險，來進行組合投資。不能把雞蛋放在一個籠子里面金融投資的基本原則是低買高賣需要定期的分析和評估自己目前資產而知識投資也很類似，對于一個程序員，對自己的知識投資也有... 閱讀全文

摘要： 采用面向服務的架構設計的系統，隨著服務越來越多， 面向服務的架構也會帶來的副作用，會有盲區，也會有雷區副作用：1 業務被分成獨立的單元，服務高度的自組織性，每個人只關于自己負責的單元，自己提供的服務和引用其他單元的服務，缺乏對系統整體的了解。而對整體視圖了解的人相對決定業務的質量。2 溝通成本比較高，雖然開發可以并行，但是由于溝通的成本，導致效率低下。盲區：從戰略目標到最后業務的實現，由于業務分割成多個獨立的單元，每個單元的理解程度不一樣，導致最后業務偏離整體目標。例如戰略目標是100%，不同單元的理解程度為90%，如果有5個單元，目標會有90%*90%*90%*90%*90% = 59%雷區 閱讀全文

摘要： 隨著公司的架構逐步發展，越來越多的問題被提出來，也發現一個良好的技術架構需要考慮的問題1 架構的可擴展性這里面又包括以下幾個方面水平垂直可拆分服務無狀態數據可緩存可異步處理（提高性能）可復制（提高效率）無單點設計2 架構的可管控性這里面又包括以下幾個方面服務可監控性支持服務降級升級故障可隔離（可禁用）發布可回滾3 架構的可測性可測試4 架構的可部署應用程序和數據可分開部署支持多數據中心的支持多異地災備以上就是一些技術架構需要考慮的問題，可能對于每個點不同的業務，不同的系統要求不一樣，但是總體來說，都是作為一個架構師要考慮的。 閱讀全文