利用ElasticSearch和Redis檢索和存儲十億信息

1、利用 ElasticSearch 和 Redis 檢索和存儲十億信息HipChat 但是如果從賺錢的角度上看，企業(yè)市場的高收益確實值得任何公司追逐，這也正是像JIRA Confluence 這樣的智能工具制造商Atlassian 2012 年收購HipChat 的原因。同時，或許你不知道的是，在Atlassian已經(jīng)進入了一個指。12 翻一番。HipChat 給我們展示了一個通用AWS 上，在某一個拐點之后，你開始走向云特性，也就是橫向擴展，這就是HipChat所做的事情。然而HipChat 的發(fā)展也并未是順風順水，安全性的擔憂推動了HipChat 的云（SaaS）版本之外內(nèi)部部署版本的發(fā)展。

2、即使HipChat 沒有谷歌那么大規(guī)模，我們?nèi)阅軓闹袑W(xué)到好東西，比如他們?nèi)绾渭皶r索引和搜索十億信息，這也是IRC之類和HipChat丟失信息是一個艱巨的挑戰(zhàn)。這是HipChat 選擇的路，我們一起展開統(tǒng)計平臺60 12 億文檔存儲4TB 的EBS RAIDAWS 8 個ElasticSearch 服務(wù)器26 個前端代理服務(wù)器，是后端應(yīng)用服務(wù)器的一倍18 個人0.5TB 的搜索數(shù)據(jù)主機：AWS EC2 East 上的 75 個實例全部使用Ubuntu 12.04 LTS數(shù)據(jù)庫：目前用于聊天記錄的CouchDB，過渡到ElasticSearch。MySQL-RDS于其它的一切產(chǎn)品緩存：Redis搜

3、索：ElasticSearch隊列/Worker 服務(wù)器：Gearman（隊列），Curler（Worker） 語言：Twisted Python（XMPP Server）和PHP（Web 前端系統(tǒng)配置：開源Chef+Fabric代碼部署：Capistrano監(jiān)控：Sensu 和monit 將警告抽送至Pagerduty圖：statsd + Graphite占用大部分流量的并不是聊天信息，而是狀態(tài)信息、idle、available），人們連 接/60條消息似乎很少，但是它只是一個平均水平。通知中心HipChat有助于使每個人都在消息圈內(nèi)，特別是遠程辦公。使用HipChat而不是IRCHipCh

4、at便你以后搜索它們。強調(diào)搜索，這個特性的好處是你可以在任何時候做回溯，了解發(fā)生了什么和同意了什么。如果在發(fā)送一條信息時，你的設(shè)備無法訪問，它也會將消息路由到同一個用戶的多臺設(shè)備中，并做臨時消息緩存/重試。從他們的API集成中看到增長。存儲和搜索信息是系統(tǒng)中主要的可擴展性瓶頸。HipChat 使用XMPP XMPP （WindowLinuxMaciOS并帶有類似PDF瀏覽、自定義表情符號、自動用戶注冊等擴展。在以前，將Wiki 多已在企業(yè)落腳，這是為什么？IM 和Skype 天工具是自然的事情。異地工作模式的崛起。團隊越來越分散，我們不能只是坐在一起進行一個講座，一切文檔化的需要意味著組織通信

5、將有一筆巨大的財富。GIF 動畫等功能做得生動有趣，會吸引更廣泛的群體。HipChat有一個API，這使得它可以編寫類似IRC bots這樣的工具。例如使用Bitbucket10:08開發(fā)者X提交一些代碼來修復(fù)一個漏洞。代碼發(fā)送通過HipChat Bitbucket 提交會擊中一個web addons Addons 幫助編寫B(tài)itbucket 賬戶。比如我有我的API 令牌，我想在每次提交發(fā)生時張貼到這個API GitHub。在客戶端Adobe Air 啟動時，內(nèi)存泄露會導(dǎo)致宕機，因此將其移動到本地應(yīng)用上。這是個麻煩，也是機遇。同一個公司中都存在許多跨平臺跨部門的用戶，你需要站在用戶的角度思考

6、。希望用戶在所有的系統(tǒng)中都有很好的體驗，用戶不僅僅是技術(shù)人員。XMPP 服務(wù)器架構(gòu)HipChat 是基于XMPP 日志輸出的長段等等。他們不想談?wù)撟约旱腦MPP架構(gòu)，所以沒有很多的細節(jié)。他們沒有使用第三方的XMPP 服務(wù)器，而是利用Twisted Python XMPP 庫建立不用在其它代碼庫上修改。AWS 上的RDS 用于用戶身份驗證和其它使用事務(wù)及SQL 的地方。這是一個穩(wěn)定、成熟的技術(shù)。對于內(nèi)部部署的產(chǎn)品，則使用MariaDB。Redis 所以，你連接的是哪個XMPP服務(wù)器本身并不是一個限制。痛點是Redis（還）沒有集群，因此使用了高可用性的hot/cold 模式，所以，一個從屬節(jié)點已

7、經(jīng)準備就緒。故障轉(zhuǎn)移從主節(jié)點到從屬節(jié)點大概需要7 的發(fā)布是手動的，不是自動的。提高負載可以發(fā)現(xiàn)代理服務(wù)器中的弱點所在，也可以清楚能支撐多少個客戶端。用戶更愿意晚點接收信息，而不是根本沒有信息。6XMPP接受的延遲。連接不僅來自客戶端，還來自bots支持他們的程序設(shè)計界面。在第一遍的時候，他們分離出前端服務(wù)器和應(yīng)用服務(wù)器。代理服務(wù)器處理連接，后端應(yīng)用程序處理的stanza息發(fā)送數(shù)量驅(qū)動。保持那么多的連接打開，同時提供及時的服務(wù)是一個挑戰(zhàn)。Twisted 是他們有很多的連接，所以必須弄清楚如何更好地處理這些連接。存儲架構(gòu)HipChat 10 億條，同時還在不停增長，他們將CouchDB 和Luce

8、ne 對存儲和搜索信息的解決方案推向極限。認為Redis 將會是故障點，而Couch/Lucene 會足夠好。沒有做合適的容量計劃和Redis 而應(yīng)該專注于數(shù)據(jù)存儲。當時他們相信通過增加容量來擴展，向上移動到越來越大的亞馬遜實例。他們發(fā)現(xiàn)一點，隨著不斷地增長，他們利用這種方法只能再工作兩個月。所以，他們不得不采用其他的辦法。Couch/Lucene 因。在亞馬遜上大約 10 億消息的一半是一個臨界點。用一個專用的服務(wù)器和200G RAM，他們之前的架構(gòu)可能仍能工作，但在有限資源的云上就不能工作了。他們想留在亞馬遜。喜歡AWS 的靈活性，性能的添加只需要通過租用實例完成。你必須要處理它，否則一些

9、用戶將會失去流量。以隨時關(guān)閉節(jié)點。關(guān)閉一個Redis 主節(jié)點，可以在 5 4 個可用地區(qū)，但是還沒有多區(qū)域。EBS 1TB 的數(shù)據(jù)。在遇到之前，他們并不知道這個限制。使用Couch 時他們遇到了EBS HipChat 0.5TB2TB的RAID在周末壓縮過程中遇到了限制，不想使用RAID解決方案。不選擇亞馬遜的HipChat的托管服務(wù)。HipChat 服務(wù)器驅(qū)動技術(shù)堆棧的決定。私人版是建立在自己主機上的解決方案。某/SaaS 國際客戶，因此聘請了兩名工程師創(chuàng)建產(chǎn)品的安裝版本。Redis 集群可以自托管，也可以像ElasticSearch 那樣工作在AWS 版本中他們使用MariaDB，而不是R

10、DS。不能考慮一個完整的SaaS解決方案，因為那會是一個鎖定。現(xiàn)在過渡到ElasticSearch移動到ElasticSearch作為他們的存儲和搜索后端，因為它可以儲存他們的所有數(shù)可以通過分區(qū)和復(fù)制透明的處理節(jié)點損失，并且它建立在Lucene之上。并不真的需要一個MapReduce BigCouch 和Riak （表現(xiàn)一般ESGETESHA 已令他們在系統(tǒng)的堅固性上感到非常有信心。Lucene的兼容是一個巨大的勝利，因為所有的查詢都已經(jīng)兼容Lucene一個自然的遷移路徑?？蛻魯?shù)據(jù)是相當多樣的，從聊天記錄到圖像響應(yīng)類型的差別也隨處可見，他們需要能夠快速地直接從 12 億文檔中查詢數(shù)據(jù)。此舉正變

11、得越來越普遍HipChat也使用ElasticSearch作為他們的key-value存儲，10ms100ms某些領(lǐng)域仍然超過Couch。那為什么還要用多個工具？使用ES，一個節(jié)點故障不會引起任何人的注意。在它再平衡時你會得到CPU 率過高的警報，但是系統(tǒng)仍然運行。8ES去處理流量的增長。Java的產(chǎn)品JVM調(diào)整可能非常棘手。要使用ES，必須有堆空間容量計劃。ES 8 22G 閉緩存。有少數(shù)用戶會注意到這個問題。因為網(wǎng)絡(luò)的不可靠，Amazon 誤的選舉發(fā)生。使用ElasticSearch 6 ES GC 暫停并在網(wǎng)絡(luò)中丟失。那么其他人就不會不需要法定人數(shù)。因此就會出現(xiàn)SplitBrain問題，

12、從而引起很多問題。解決方案是在專用的節(jié)點上運行ElasticSearch 主節(jié)點，從而避免了后續(xù)問題。主節(jié)點處理分片的分配是完成，誰是主要的，并且完成復(fù)制分片分布圖。實現(xiàn)再平衡要容易的多，因為主節(jié)點可以性能優(yōu)良的處理所有的再平衡?？梢圆樵?nèi)魏喂?jié)點，并會做內(nèi)部路由。使用月索引，每個月是一個單獨的索引。每個初級索引有8 本。如果一個節(jié)點丟失，系統(tǒng)仍能工作。不要把RDS移動到ES中。需要使用SQL的數(shù)據(jù)一般儲存在RDS/MariaDB中，典型的是用戶管理數(shù)據(jù)。Redis /從設(shè)置。有一個Redis 統(tǒng)計服Redis 75 不間斷的訪問數(shù)據(jù)庫。也有內(nèi)部狀態(tài)或快速數(shù)據(jù)的狀態(tài)，比如登入用戶數(shù)量。常規(guī)Gea

13、rman用于異步工作，比如iOS的推送和傳遞電子郵件。AWS West用于災(zāi)難恢復(fù)，一切都會備份到AWS West。ChefElasticSearch有一個很好的Chef手冊，輕松上手。像因為你可以開始寫Ruby 代碼而不是使用Puppet 風格的DSL，它也有一個很好的活躍的社群。Atlassian 所以相信，是有原因的?？梢栽趦?nèi)部要求，例如，如何擴大ElasticSearch ，當別人在Atlassian需要幫助時，他們可以加入幫忙的隊伍。良好的整體體驗。扁平的團隊結(jié)構(gòu)。仍然是一個小團隊，目前大約有18 人。兩個人在DEVOPS，少數(shù)平臺，IOS、Android 的開發(fā)人員在服務(wù)器端，一個

14、Web 開發(fā)工程師（在法國）。Capistrano 用于部署所有的主機。Sensu 用于監(jiān)控應(yīng)用程序。讓你無需監(jiān)視堆空間ElasticSearch 節(jié)點，然后在沒有任何通知的情況下解決OOM 75，這正是他們想要的狀態(tài)。Bamboo 用于持續(xù)集成?？蛻舳税姹具€不正規(guī)，開發(fā)者驅(qū)動，有一個臨時區(qū)域進行測試。集團標志?？梢钥刂颇男┤后w得到了一個功能、測試特性能及緩慢釋放特性，除此之外還能幫助控制主機的負載。ElasticSearch 他們可以關(guān)閉一個功能，并回去找Couch。用戶不會注意到差別。在Couch 和ElasticSearch 之間的過渡階段，他們都有應(yīng)用復(fù)制到兩個存儲。新的API 版本將

15、使用Oauth，因此，開發(fā)人員可以使用HipChat API 在自己的服務(wù)器上部署。有客戶使用自己的服務(wù)器是一個更具擴展性的模式。未來20 ElasticSearch 20 不確定如何處理負載的預(yù)期增長。預(yù)計要到Amazon West 以獲得數(shù)據(jù)心更多的的可用性和可能在不同的數(shù)據(jù)中心投入更多的用戶。AWS自動擴展能力移動到語音，私人一對一視頻、音頻聊天、基本的會議將來可能使用RabbitMQ來傳遞消息Confluence 更大的集成。使用HipChat 聊天，然后使用Confluence 細節(jié)。經(jīng)驗教訓(xùn)但是如果你成功賣出，那就會獲得豐厚的利潤，所以你應(yīng)該考慮企業(yè)市場HipChat 100%依靠

16、AWS，那你的系統(tǒng)移動到另一個數(shù)據(jù)中心將變得幾乎不可能。這對Netfix 少的錢去縱向擴展，給自己幾個月的喘息之機。選擇不會失敗的。HipChat 個優(yōu)先級反映給保存聊天記錄到磁盤，在宕掉后系統(tǒng)恢復(fù)時會重新加載。進入本地。你的客戶在許多不同的平臺上，一個本地的應(yīng)用將會提供最好的體驗。對于 說得通的，這樣你可以建立更好的產(chǎn)品。在生產(chǎn)和測試中關(guān)閉功能，那么你就不用擔心發(fā)布新的構(gòu)建項目了。ElasticSearch 應(yīng)對增長的橫向擴展能力讓HipChat 樣也會有一個很好的用戶體驗，這才是最重要的。成為該流程的一部分HipChat 作為人和工具之間的天然契合點，也是來編寫實現(xiàn)各種有用工作流bots 的天然點。這使得HipChat 在企業(yè)中有發(fā)揮要你。AWS 這個要求看起來有點荒謬，但是在云環(huán)境下卻非TCP 的連接技術(shù)和心跳，去猜測另一個節(jié)點是否發(fā)生故障，從而導(dǎo)致 Split Brain 問題及啟用備庫時產(chǎn)生數(shù)據(jù)