阿里技術分享：阿里自研金融級數據庫OceanBase的艱辛成長之路
本文原始內容由做者「陽振坤」整理髮佈於OceanBase技術公衆號。php
一、引言
OceanBase 是螞蟻金服自研的分佈式數據庫，在其 9 年的發展歷程裏，從艱難上線到找不到業務場景瀕臨解散，最後在雙十一的流量考驗下浴火重生，成爲螞蟻金服所有核心繫統的承載數據庫。這一路走來的艱辛和故事，螞蟻金服高級研究員、OceanBase 團隊負責人陽振坤將爲你娓娓道來。html
什麼是OceanBase數據庫？前端
是阿里巴巴集團自主研發的分佈式關係型數據庫，融合傳統關係型數據庫強大功能與分佈式系統的特色，具有持續可用、高度可擴展、高性能等優點。普遍應用於螞蟻金服、網商銀行等金融級核心系統。 在2015年雙11承載了螞蟻核心鏈路100%的流量，創下了交易、支付每秒支付峯值的新紀錄，在功能、穩定性、可擴展性、性能方面都經歷過嚴格的檢驗。程序員
（本文同步發佈於：http://www.52im.net/thread-2072-1-1.html）算法
二、關於做者
陽振坤：博士、YOCSEF榮譽委員。數據庫
1984年進入北京大學，前後得到數學學士、碩士以及計算機博士學位後留校，1997年破格晉升爲教授，1999年成爲北京大學首批「長江學者獎勵計劃」特聘教授之一；編程
前後得到北京市科學技術進步獎一等獎、國家科學技術進步獎一等獎（排名第四）、第六屆中國青年科技獎、北京市五四青年獎等；緩存
曾前後擔任方正研究院副院長、北大計算機研究所副所長、聯想研究院首席研究員、微軟亞洲研究院主任研究員、百度高級科學家等；服務器
現擔任淘寶研究員，主持淘寶海量數據庫系統的研究和開發。微信
三、相關文章
《騰訊資深架構師乾貨總結：一文讀懂大型分佈式系統設計的方方面面》
四、數據庫：技術和市場的「死亡之谷」
數據庫在每一個人的生活裏無處不在，無論是通信、交通、金融行業，抑或是天天你們都在接觸的互聯網，全部這些業務的背後都是數據庫在支撐。
▲ 螞蟻金服 OceanBase 團隊負責人陽振坤
數據庫經歷了近半個世紀的發展，在理論上很成熟，在技術應用上也已經很是成熟了。
可是數據庫恰恰有一個特別高的門檻，緣由是數據庫有三條特別苛刻的要求：
1）事務須併發處理： 數據庫要支持事務，全部人都但願用最小的處理資源，作到最大價值的事情。因此事務持續要作大量的併發處理；
2）數據一條不能錯： 一個數據庫若是數據錯了，就永遠沒有機會了。對於使用者而言，若是你會錯一條，你就有可能會錯一千、一萬條，這是沒有公司願意承擔的風險；
3）服務片刻不能停： 通信系統、列車系統，甚至飛機航行系統的背後都是數據庫在支撐，這些系統一旦啓動，一分一秒都是不能終止的。
上面提到的這三條要求，任何兩個其實都好知足。可是你們仔細想想，這三個要求若是要同時知足，就會變得極其困難。
同時，數據庫又是一個巨大的市場，對國家、對整個社會都很是重要。這就致使不少國家、不少企業都想作也正在作這件事，可是結果你們都作到了同一個思路上。後來者都成了先行者的模仿者，那麼這個模仿的代價就會變得很大。
今天做爲一個後來者，你再去作這麼一套數據庫系統的時候，就真的很難說清楚你與先行者相比有多大的優點。這也就形成了強者恆強、寡頭壟斷的局面，後來者很難居上。
數據庫一樣也有開源這條路徑，好比你們都瞭解的 MySQL。開源是免費的，對於不少對成本敏感的公司而言開源數據庫成爲了替代商業數據庫的另外一種選擇。
那麼在面對數據庫的「死亡之谷」這樣的困境下，爲何咱們還去花這麼多錢，投入這麼多設備，花這麼多年時間和人力再去作一個數據庫，究竟它的意義在哪兒？它又可以產生多大的經濟價值？
既然有了開源的數據庫，阿里巴巴和螞蟻金服還要作這麼一個商業數據庫產品，其實這裏面是有本質緣由的。不少人知道阿里巴巴今天已經 全面去 IOE：去掉了 Oracle 數據庫、IBM 小型機、 EMC 存儲。那麼不少人就在想，能不能在其餘的行業，在鐵路、交通，電信、政府這些行業推而廣之，所有完成去 O 的進程呢？這個答案是否認的。
由於像阿里巴巴發展的這一套系統是基於 MySQL 的開源數據庫，跟商業數據庫在功能和性能上實際上是有很大差距的。阿里巴巴當時在用它的時候，有不少事情數據庫是作不了的，那麼這些作不了的事情當時就放在應用軟件裏作。因此阿里巴巴在數據庫和應用軟件上都投入了很大的技術力量。這套系統拿到外部業務去用是不能完全解決問題的。本質上這套系統是服務於阿里巴巴的專用系統，而不是一個通用的系統。
那麼有人會問，在個人企業裏，若是真的想去掉 IOE，該怎麼辦？你一樣要投入兩撥人，一撥人要去作數據庫，針對你的企業的需求來作相應的修改；還有一撥人要去作應用系統。可是問題是並非全部的企業都像阿里巴巴有這麼多優秀的技術人員，這套東西其實很難去直接推廣應用。
因此，從一開始咱們作 OceanBase 的目標就是——咱們不想只作一個專用的系統，要作就必定要作一個通用的系統。咱們但願從此 OceanBase 可以服務於各行各業，不再須要企業投入幾十幾百甚至幾千我的去改造、去從新作一套業務系統。
五、OceanBase 的機遇與創新
當時作 OceanBase 數據庫一個最根本性的緣由就是需求的變化。由於這麼一套基礎系統，若是背後沒有需求的變化，從 0 到 1 本身作出來基本是不可能的。
2010 年春夏之際，我來到了阿里巴巴。去了以後發現當時有兩個因素影響了阿里巴巴關係數據庫的應用。
一個因素是併發，數據庫它是按照併發量來賣錢的。說直接點，就是按照處理器來賣錢。之因此要買這麼多處理器就是由於業務有這麼大的需求。那麼傳統的業務好比商場，一個商場就那麼幾個收銀臺，它是一個相對穩定並且比較小的併發量，大多數狀況就是幾十幾百的併發量。
▲ 陽振坤分享經驗心得
隨着互聯網的高速發展，阿里巴巴天貓雙 11 幾乎徹底改變了過去行業內相對穩定的併發量，突破了幾百萬人甚至是千萬人的同時在線購買。這個併發量跟過去的傳統業務場景相比是幾個數量級的增加，按照這個數量級去買商業數據庫，沒有一家企業買得起。
還有一個因素，當時咱們叫它建站，其實就是搭建一個數據庫。過去建一個商場，建一個銀行的分店，這個週期是很是長的，有足夠的時間來規劃 IT 業務系統。互聯網業務是等不了的，就像當時 OceanBase 接的第一個業務給到咱們的時間就是最多一個星期。現實是一個星期的時間根本連小型機的安裝調試都完不成。
原來的模式已經徹底沒法支撐互聯網快速發展的業務。因此這兩個需求的變化，是催生咱們本身來作數據庫的很關鍵的因素。
六、OceanBase 關鍵性的技術革新
當時我找了幾個同事商量這個事情，我跟你們說，咱們是天時地利人和都遇上，這件事情除非是被拍死掉，不然咱們是確定要把它作成的。這個過程真的很是艱辛，咱們花了差很少五年的時間，才真正讓 OceanBase 有了關鍵的應用。
過去作數據庫的公司，無論是國內仍是國外，你們都是爲了作數據庫而作數據庫，那麼最後結果就是全部作傳統數據庫的廠商，你們的方案都很像。
由於數據庫有很成熟的理論和工程的方法，那麼若是咱們按照以往的原則作過去，結果確定也是同樣的。因此，其實咱們走了另一條路——作分佈式。最先作這個東西可能都不叫數據庫，它更像是一個分佈式系統，可是支持了事務的特性。這條路後來被證實確實是具備特別大的價值和意義。
當時咱們在作 OceanBase 的時候，首先肯定了幾件事情。第一件事就是咱們要作分佈式，由於咱們的業務要建站，不作分佈式靠大型機和小型機是不可能作獲得的。
另一件事是成本，什麼東西最便宜，量最大最主流的東西最便宜，它就是 PC 服務器。小型機少則幾十萬，多則幾百萬，PC 服務器頂多就是幾千幾萬塊的成本。
第三個要解決的就是可靠性問題。你們對數據庫的指望是永不宕機，永遠不出問題。但是 PC 服務器處處都有，性價比也很是好，可是不容忽視的是它的故障率高。普通 PC 服務器它遠遠達不到數據庫所要求的年可靠性五個九的要求。對普通 PC 服務器而言，差的多是兩個或者三個數量級，因此咱們得首先把這個問題解決掉。咱們用的就是分佈式的辦法來解決。
咱們運用的是分佈式的一致性協議，直白一點就是一個多數派的選舉和投票協議。同時，咱們把修改的增量直接放在內存裏，每次要查詢的時候，把內存硬盤的數據作一個 merge，那麼天天在業務相對的低谷期，再把內存中的數據整理回硬盤去。
作到了這幾件事情，這個系統就有了很好的性價比，咱們的成本比傳統的數據庫至少低一個數量級，你只須要用普通的 PC 機，不須要用昂貴的硬件設施。同時，擴展能力會也變得很好。
七、OceanBase 的第一個業務：淘寶收藏夾
理想看起來很美好，可是現實特別骨感。這個項目剛啓動的時候，咱們好不容易纔找到了幾我的，人手是嚴重不足的。另一個更大的挑戰是時間：在作 OceanBase 數據庫以前，我去找個人老闆，他說給你 兩年時間 若是能把一個數據庫作出來就能夠。當時我內心想兩年雖然對於作數據庫來講時間確實過短，可是這兩年對於那時候的咱們而言已經足夠支撐起最初的想法了。
技術最終仍是須要經過業務落實下去，因此我找了一批業務方，花了很長時間跟對方溝通，最後終於有一個業務願意用咱們的數據庫。當時他給個人時間期限是——兩個星期。
當時我就傻了，兩個星期要作個數據庫，這可怎麼辦？後來跟業務的同窗反覆討論，最後他們贊成說，大家先作個 demo 出來。因而咱們就花了兩個月吭哧吭哧的作了一個 demo 出來。他們看了之後以爲比較滿意，後來這個事情就一直堅持作下去了。
最後，我記得是到了第八個月的時候，系統上線了。這個業務就是如今你們都在用的——淘寶收藏夾，這是 OceanBase 的第一個業務。若是沒有這個業務，咱們如今也活不下來。
▲ 淘寶收藏夾業務
那麼這個業務到底有什麼特殊的地方？每一個人都用過淘寶收藏夾，每次你打開收藏夾的時候，數據庫在背後其實作了不少事情：咱們以單個商品爲例，它須要到一個叫商品庫的地方，逐條紀錄覈對，看看商品有沒有下架，有沒有參與促銷，有沒有參加其餘的返點活動等等。
假如你收藏了 100 多件商品，它就要進去一條條的取出來看。本質上來說，這就意味着一百屢次的隨機 IO。那麼當不少人同時來看的時候，其實一個 IO 就被放大了幾百倍，這時候有多少個硬盤都不夠用。
當時他們已經用了幾十臺服務器了，按照業務的預估，第二年他們要買 400 臺機器，第三年的數量都不敢想象。當時咱們想了一個辦法——咱們作了一個 寬表，確切的講應該稱爲 物化視圖。
▲ 淘寶收藏夾的寬表
首先咱們把每一個用戶收藏的信息彙集起來，這樣能夠減小 IO，而後把收藏的商品放在這個列表裏。可是咱們怎麼避免去訪問一百屢次 IO 呢？咱們的辦法就是找到一個時間點，當時是設定在天天晚上凌晨兩點。在這以前，咱們就把這些信息所有 merge 到硬盤，而後從兩點開始，咱們把新的修改都放在內存裏面。
因此每到兩點的時候，咱們把兩點以前全部的信息都合到這張表裏，那麼這張表裏的信息在兩點整的時候是準確的，這時候咱們不須要去訪問商品庫。兩點以後的修改，包括商品庫的修改是在內存裏進行的，這時候若是要看這些商品有哪些修改，商品只需訪問內存中的更新便可。
因此其實咱們就是經過這樣一個手段，把每次收藏夾的展現，由原來的一百屢次 IO 變成了一次。咱們一會兒就把淘寶收藏夾業務的整個 IO 降下來了。當時 OceanBase 確實是幫助業務實際解決了他們的問題，使得業務可以更好的快速的發展。業務是必定要發展的，因此只有咱們真正可以解決他們的問題，咱們這些作基礎系統作底層的人，才能活下去。
▲ 淘寶收藏夾架構圖
這是當時給淘寶收藏夾作的一個架構，中間是一個作修改的服務器，全部的修改都在這一臺機器上進行。旁邊的機器是基線數據，就是分片切片之後，放到周圍這一圈進行。因此當時咱們就用這個看上去很簡陋的一個方案來真正解決了淘寶收藏夾的問題。
當時收藏夾用了這個方案以後，服務器的數量從原來預計的第二年要用幾百臺，最後其實只用了差很少二十幾臺服務器，就把整個問題解決掉了。
八、OceanBase 0.3-0.4 版本：團隊面臨解散
從淘寶收藏夾項目以後，咱們陸陸續續也作了很多項目，可是沒有一個項目能像淘寶收藏夾這樣對業務有明顯的價值和貢獻。
從那以後的整整兩年，咱們找不到對 OceanBase 數據庫而言特別有價值的業務。那兩年對於咱們而言特別特別困難，甚至整個團隊隨時面臨着解散。
2012 年末，公司把咱們從淘寶調到支付寶，當時預估到支付寶在數據庫方面所面對的挑戰更大，後來證實確實如此。即便是這樣，當時仍然還處在一個很是困難的時期。到了支付寶一年多的時間，咱們仍然很難找到新的業務，或者說價值比較大的業務來證實咱們的價值。
九、OceanBase 0.5 版本：成功抗住 10% 流量
2013 年的夏天，支付寶但願全面去掉 IOE——去掉 IBM 的小型機，Oracle 的數據庫和 EMC 的存儲。當時面臨了一個問題，就是去掉以後是能夠用 MySQL 來代替 Oracle，可是 MySQL 的主備鏡像實際上是作不到主備徹底一致的。
這個時候咱們意識到：OceanBase 的機會來了。由於咱們能夠經過分佈式的選舉跟投票來作，哪怕硬件自己不可靠，咱們也能保證數據的不丟失。傳統數據庫本質上是藉助硬件的可靠性，也就是硬件須要達到五個九的可靠性來實現高可用的。就算出了故障，它的數據也能救得回來。可是這種手段須要很是高的成本，同時沒有足夠的擴展能力。
銀行雖然有很高的可用性，可是它的高可用性是用很高的硬件成本換來的。咱們建議必定要淘汰這些高可靠的硬件，由於他們的成本實在過高了。一旦真的使用了高性能，高性價比的 PC 服務器，那麼你就不可能再花那麼多錢去買高端的硬件。
因此我當時內心很明白，若是這件事情咱們作不成，這個項目就只有死路一條。
那麼，OceanBase 到底如何作到主備徹底一致的呢？理論上咱們也沒有辦法說徹底作到主庫備庫的一致。咱們用了另一個辦法：主庫仍是主庫，仍是須要它快速的作事務，但同時主庫還要把事務的日誌同步給至少兩個備庫。兩個備庫中至少有一個收到了，那麼加上它本身就超過了半數，或者咱們叫多數派。當多數的節點收到了這個事務，而且把它持久化到硬盤了，咱們就認爲這個事務是成功的。
因此這時候任何一臺機器壞掉，每筆事務在剩下兩臺機器裏面至少一臺存在。因此說即便主庫忽然壞掉，另外兩臺機器通過握手，它們再選舉出一個新的主庫，那麼確定能夠繼續工做下去，同時能夠保證數據是沒有損失的。
2014 年的時候，咱們在會議室裏討論 支付寶交易庫的上線，當時吵得面紅耳赤，爭論了好久別人就是不肯意上 OB。他們原來的交易、支付系統全都在 Oracle 上，當時的 Oracle 不管是在穩定性、可靠性仍是性能方面，確定比 OceanBase 要好得多。因此沒有人願意用。
最後，在 魯肅（螞蟻金服 CTO） 的力挺下決定切給 OceanBase 1% 的流量試試。由於那幾年業務發展的太快，當時 Oracle 的共享存儲已經扛不住這個流量，按照當時的業務流量去作壓測的時候，幾分鐘就要壞一塊盤。最後發現，把業務切掉 10%，才能勉強扛得住。因此那一年的雙 11 就把 10% 的流量切到了 OceanBase。OceanBase 也成功扛過去了那一年的雙 11。
十、OceanBase 1.0 版本：惟一支持分佈式事務的商業數據庫
可是其實在 0.5 這個版本上線的時候，咱們內心很是清楚，這個版本是臨時的。咱們當時選擇作多數派協議的時候，仍是用了原來的想法，每一個集羣仍是中間有一箇中心節點。這個事情必定不會是長久持續下去的，咱們知道這個必定會遇到問題。因此當時其實交易庫尚未徹底上線，咱們就已經啓動了 1.0 版本的開發。
2014 年到 2016 年，整整兩年的時間，咱們投入了 40 多我的，所有投在 OceanBase 1.0 版本的開發上。整整兩年，這 40 多我的沒幹任何別的事情。全部的線上問題，版本修改、升級都是咱們調出來的五個同窗所有扛下來的。
有人會問什麼樣的因素讓這麼多人作了兩年才能把這個版本作出來？這個版本里面咱們主要作的一件事就是分佈式。
若是你問分佈式事務有這麼難嗎？我能夠自豪地回答你：今天的商業數據庫裏有且只有一個是可以支持分佈式事務的，它就是 OceanBase。
OceanBase 經過分佈式的一致性協議作到了系統的高可用性，就是說哪怕咱們今天用的是比較廉價的，可靠性比較低的 PC 服務器，可是咱們的可用性其實會變得更高。由於單機的故障咱們徹底可以自動的容忍掉，並且咱們作到了如今的數據作不到的一件事情——哪怕主庫出故障，咱們可以保證數據沒有任何損失。
今天的銀行每一年國家都要求他們至少作一次消防演習，銀行要到最前端的網關把交易紀錄撈出來覈對，把這些帳對平了，備庫才能繼續服務。咱們今天根本沒有這個問題，主庫出故障了，也就是幾十秒之後，新的主庫就會被選出來。由於只要剩下的機器超過半數，他們互相之間會經過握手把數據補齊，很快就能工做。其實這 30 秒大部分仍是消耗在肯定主庫是否真的有故障。
因此，咱們用不可靠的硬件反而作到了更高的可用性，並且作到了數據真正的一致。
傳統的數據庫由於涉及到共享存儲，共享存儲是一個單一的設備，你只能放在一個機房。因此一旦那個機房出現了故障，你就只能靠備庫容災把系統恢復起來。
OceanBase 經過「三地五中心」部署實現城市級故障自動無損容災。比方說至關於你一共寫了五份日誌，放在三個不一樣的城市裏。任何一個城市哪怕出故障，比方說杭州斷網了，那麼剩下的依然超過半數，這個系統仍是能夠恢復工做的。這也是原來的傳統數據庫，無論想什麼辦法，都作不到的事情。
▲ 2018年 9 月 20 日雲棲大會 ATEC 主論壇現場剪光纜實況
前段時間，你們可能也看到了雲棲大會的新聞。螞蟻金服副 CTO 胡喜在 ATEC 主論壇現場模擬挖斷支付寶近一半服務器的光纜。結果只過了 26 秒，模擬環境中的支付寶就徹底恢復了正常。而這場 26 秒自斷服務器現場演示的技術核心其實正是基於 OceanBase 的三地五中心架構方案。
2017 年，天貓雙 11 中螞蟻金服的所有核心繫統，包括不少業務系統都放在了 OceanBase 上。去年咱們創造了 25.6 萬筆 / 秒 支付峯值的世界紀錄，這下面還有一個數據，就是說咱們爲了要執行這 25.6 萬筆的支付，執行了 4200 萬條 SQL。
十一、新的歷史機遇：走出去
因此從今天來看，OceanBase 在過去的歷史進程中面臨了一個個新的機遇，不管是處理器、操做系統仍是數據庫，這些都是很是大的挑戰。
從 2016 年末，咱們就開始作準備，OceanBase 必定要走出去。從咱們成立的第一天起，團隊裏的每一個成員的目標都是一致的：咱們不是想作一個數據庫只是給本身用，咱們要作一個數據庫真的去推進整個社會的進步，可以讓整個社會的生產力發生變化。
因此，2017 年咱們正式開始服務於外部，最先的兩家客戶是 浙商銀行 和 南京銀行，咱們如今的客戶要多不少。從內部的應用到真正走出去服務於外部，真的是一個很大的挑戰，是一件很困難的事情。
回想這八年多來，OceanBase 走過的路：開始的頭兩三年，咱們真的天天都在掙扎，每分每秒都在想着怎麼能讓本身活下來。到了 201三、2014 年，咱們終於找到了一個真正的立足點，就是支付寶的交易庫。而後咱們接着花了整整兩年的時間，真正在 OceanBase 1.0 版本把分佈式作出來。在接下來的一到兩年時間裏，咱們把支付寶的核心業務所有搬到 OceanBase 上。
關係數據庫確實是個門檻很高的東西，可是凡事有利有弊。門檻高意味着咱們進來很難，別人進來同樣難。咱們集中精力在作事務處理這一塊，它的門檻是很高，很不容易進去，但咱們偏偏有這個機會能進去。咱們費了很大的力氣跨進來了，別人可能費了所有力氣也進不來。
如今回想起來，可以把最先的一些想法一些創新變成產品，真的是很是辛苦或者說很是痛苦的一條道路。可是咱們作的全部事情其實仍是從業務、從客戶中出發，只有技術真的可以落到生產中去，落到用戶中去纔是真正有價值的，不然你作得再好也是一個空中樓閣。
到了今天，當咱們走出阿里巴巴，走出螞蟻金服再來看，發現當你作的事情可以提供十倍性價比的時候，其實真的有機會去顛覆一個產業，從新塑造一個行業。
附錄：更多精華文章彙總
[1] 有關大型互聯網系統架構設計的文章：
《一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)》
《IM開發基礎知識補課(二)：如何設計大量圖片文件的服務端存儲架構？》
《IM開發基礎知識補課(三)：快速理解服務端數據庫讀寫分離原理及實踐建議》
《IM開發基礎知識補課(四)：正確理解HTTP短鏈接中的Cookie、Session和Token》
《WhatsApp技術實踐分享：32人工程團隊創造的技術神話》
《王者榮耀2億用戶量的背後：產品定位、技術架構、網絡方案等》
《IM系統的MQ消息中間件選型：Kafka仍是RabbitMQ？》
《騰訊資深架構師乾貨總結：一文讀懂大型分佈式系統設計的方方面面》
《子彈短信光鮮的背後：網易雲信首席架構師分享億級IM平臺的技術實踐》
《知乎技術分享：從單機到2000萬QPS併發的Redis高性能緩存實踐之路》
《IM開發基礎知識補課(五)：通俗易懂，正確理解並用好MQ消息隊列》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（容災方案篇）》
《新手入門：零基礎理解大型分佈式架構的演進歷史、技術原理、最佳實踐》
《阿里技術分享：阿里自研金融級數據庫OceanBase的艱辛成長之路》
>> 更多同類文章 ……
[2] 更多感悟和思考
《一名90後二流大學程序員的自述：我是如何從「菜鳥」到「辣雞」的》
《程序員的抉擇：必須離開帝都——由於除了工做機會，還有什麼值得留戀？》
《即時通信創業必讀：解密微信的產品定位、創新思惟、設計法則等》
《程序員神級跳槽攻略：何時該跳？作什麼準備？到哪裏找工做？》
《調皮的程序員：Linux之父雕刻在Linux內核中的故事》
《老羅最新發布了「子彈短信」這款IM，主打熟人社交可否對標微信？》
《機會不給無準備的人：一個Android程序員屢戰屢敗的悲慘校招經歷》
《笑中帶淚的碼農往事：入職三天被開，公司給100塊叫我走人，有我慘？》
>> 更多同類文章 ……
[3] 互聯網大廠的技術故事：
《技術往事：微信估值已超5千億，雷軍曾有機會收編張小龍及其Foxmail》
《2017微信數據報告：日活躍用戶達9億、日發消息380億條》
《技術往事：創業初期的騰訊——16年前的冬天，誰動了馬化騰的代碼》
《技術往事：史上最全QQ圖標變遷過程，追尋IM巨人的演進歷史》
《開發往事：深度講述2010到2015，微信一路風雨的背後》
《開發往事：記錄微信3.0版背後的故事（距微信1.0發佈9個月時）》
《前創始團隊成員分享：盤點微信的前世此生——微信成功的必然和偶然》
《即時通信創業必讀：解密微信的產品定位、創新思惟、設計法則等》
《[技術腦洞] 若是把14億中國人拉到一個微信羣裏技術上能實現嗎？》
《QQ和微信止步不前，意味着即時通信社交應用創業的第2春已來？ 》
>> 更多同類文章 ……
（本文同步發佈於：http://www.52im.net/thread-2072-1-1.html）
- 1. 螞蟻金服自研分佈式關係數據庫OceanBase上線阿里雲
- 2. 阿里技術面分享
- 3. 歷程剖析：阿里雲自研HTAP數據庫的技術發展之路
- 4. 揭祕阿里服務互聯網金融的關係數據庫——OceanBase
- 5. 阿里 10 年：一個普通技術人的成長之路
- 6. 學習數據庫的艱辛之路
- 7. 阿里數據庫關鍵技術
- 8. 逆流而上:阿里巴巴技術成長之路
- 9. 阿里數據倉庫實踐分享
- 10. 個人阿里之路——阿里實習offer+校招offer|掘金技術徵文
- 更多相關文章...
- • 數據庫涉及到哪些技術？ - MySQL教程
- • Scala 函數柯里化(Currying) - Scala教程
- • 使用阿里雲OSS+CDN部署前端頁面與加速靜態資源
- • Flink 數據傳輸及反壓詳解
-
每一个你不满意的现在，都有一个你没有努力的曾经。