其他

從線程開始， 我們來看下QuartzSchedulerThread類(負責執行觸發的Trigger的工作) :  @Override public void run() { boolean lastAcquireFailed = false; while (!halted.get()) { try { // check if we're supposed to pause...

OSC開源社區 2017-04-21 11:27 分布式調度在互連網企業中佔據著十分重要的作用，尤其是電子商務領域，由於存在資料量大、高並發的特點，對資料處理的要求較高，既要保證高效性，也要保證準確性和安全性，相對比較耗時的商務邏輯往往會從中剝離開來進行非同步處理。

為什麼要用統一配置。 我們做項目時用到的配置比如資料庫配置等...我們都是寫死在項目裡面，如果需要更改，那麼也是的修改設定檔然後再投產上去，那麼問題來了，如果做叢集的呢，有100台機器，這時候做修改那就太不切實際了；那麼就需要用到統一組態管理啦。 解決思路 1.把公用配置抽取出來 2.對公用配置進行維護 3.修改公用配置後應用不需要重新部署 採用方案 1.公用配置抽取存放於zookeeper中並落地資料庫

HTTP 2.0是在SPDY（An experimental protocol for a faster web, The Chromium Projects）基礎上形成的下一代互連網通訊協定。HTTP/2 的目的是通過支援要求與響應的多工來較少延遲，通過壓縮HTTPS首部欄位將協議開銷降低，同時增加請求優先順序和伺服器端推送的支援。 本文目的是學習HTTP 2.0的原理並研究其通訊的詳細細節。大部分知識點源於《Web效能權威指南》。 1. 二進位分幀層

建立Schema Hbase 模式建立或更新可以通過 Hbase shell 工具或者使用Hbase Java API 中的 Admin類。 當列族發生變動時 hbase表必須處於 disabled 狀態。例如： Configuration config = HBaseConfiguration.create();Admin admin = new Admin(conf);String table = "myTable";admin.disableTable(

solr： 優點 1、Solr有一個更大、更成熟的使用者、開發和貢獻者社區。 2、支援添加多種格式的索引，如：HTML、PDF、微軟 Office 系列軟體格式以及 JSON、XML、CSV 等純文字格式。 3、Solr比較成熟、穩定。 4、不考慮建索引的同時進行搜尋，速度更快。 缺點 建立索引時，搜尋效率下降，即時索引搜尋效率不高。 Elasticsearch 優點

　　很早以前，做管理系統，對效能體會並不是特別明顯。因為一些使用者非常聰明，會通過調整自己的使用方式來適應系統的處理能力。現在想起來，有環境的原因也有能力的原因，沒有做好效能的事情，覺得有些好笑也有些遺憾。 　　現在做的程式，對響應速度、處理能力都有一定的要求，而且這些指標直接和效益掛鈎。這個時候，效能問題就隨著系統的運行不斷顯現出來，並在運行過程中左右一項重要任務不斷改進、調優。 　　效能最佳化的過程是一種辛苦又有趣的挑戰。

hadoop是什麼。 (1)Hadoop是一個開源的架構，可編寫和運行分布式應用處理大規模資料，是專為離線和大規模資料分析而設計的，並不適合那種對幾個記錄隨機讀寫的線上交易處理模式。Hadoop=HDFS（檔案系統，資料存放區技術相關）+

網站的可擴充性架構設計，能夠在對現有系統影響最小的情況下，系統功能可以可持續擴充及提升的能力。 在此，對容易混為一談的 “擴充性” 和 “伸縮性” 的概念進行詳細說明： 擴充性 表現為：基礎設施不需要經常變更，應用之間較少依賴或耦合，可以對需求變更快速響應。它對擴充開放，對修改關閉。架構設計會考慮到未來功能的可擴充性，所以當系統增加新功能時，不需要對現有系統的結構和代碼進行修改。 伸縮性

  大型網站技術架構（一）--大型網站架構演化 大型網站技術架構（二）--架構模式 大型網站技術架構（三）--架構核心要素 大型網站技術架構（四）--網站的高效能架構 大型網站技術架構（五）--網站高可用架構 大型網站技術架構（六）--網站的伸縮性架構             擴充性是指對現有系統影響最小的情況下，系統功能可持續擴充或提升的能力。

前言 設計一個緩衝系統，不得不要考慮的問題就是：緩衝穿透、緩衝擊穿與失效時的雪崩效應。 緩衝穿透 緩衝穿透是指查詢一個一定不存在的資料，由於緩衝是不命中時被動寫的，並且出於容錯考慮，如果從儲存層查不到資料則不寫入緩衝，這將導致這個不存在的資料每次請求都要到儲存層去查詢，失去了緩衝的意義。在流量大時，可能DB就掛掉了，要是有人利用不存在的key頻繁攻擊我們的應用，這就是漏洞。 解決方案

異地多活（異地雙活）是最近業界討論比較多的話題，特別是前一陣子支付寶機房光纖故障和攜程網資料庫丟失之後，更加喚起了技術人員們對異地容災的考慮。 而異地多活比異地容災更高一級，因為異地容災僅僅是一個冷備的概念，而異地多活卻是指有兩個或者多個可以同時對外服務的節點，任意一個點掛了，也可以迅速切換到其他節點對外服務，節點之間的資料做到准即時同步。 網上看了很多技術分享，總結了以下實踐經驗： 1 如果業務量不大，沒必要做異地多活，因為異地多活需要的營運資源成本、開發成本都非常高； 2

1 什麼是容災     容災系統是指建立兩套或多套功能相同的IT系統，互相之間可以進行健康狀態監視和功能切換。當一處系統因意外停止工作時，整個系統可以切換到另一處系統，使得系統功能可以繼續工作。     容災即使是系統的高可用性技術的一個組成部分，榮在系統更加強調處理外界環境對系統的影響，特別是災難性事件對整個IT節點的影響，提供節點層級的系統復原功能。 2 容災綜述 2.1 容災分類   &

原文連結地址：http://luyiisme.github.io/2017/04/22/spring-cloud-service-discovery-products/ 這裡就平時經常用到的服務發現的產品進行下特性的對比，首先看下結論: Feature Consul zookeeper etcd euerka 服務健全狀態檢查

透明化路由 很多開源的RPC 架構調用者需要佈建服務提供者的地址資訊，儘管可以通過讀取資料庫的服務地址清單等方式避免寫入程式碼地址資訊，但是消費者依然要感知服務提供者的地址資訊，這違反了透明化路由原則。 基於服務註冊中心的訂閱發布

TDDL大家應該很熟悉了，淘寶分布式資料層。很好的為我們實現了分庫分表、Master/Salve、動態資料源配置等功能。 那麼分布式之後，資料庫自增序列肯定用不了了，如何方便快捷的解決這個問題呢。TDDL也提供了SEQUENCE的解決方案。 下面就來簡單剖析一下實現原理。。。。。。 第一步：建立一張sequence對應的表。 CREATE TABLE `imp_sequence` (  `BIZ_NAME` varchar(45) NOT NULL COMMENT

需求是最重要的事情，失去了功能，失去了客戶的價值，軟體將一無是處。 然而，功能的實現只是架構的開端。 架構首先來自需求，需求驅動架構，然後非功能性需求反映服務等級，面對客觀環境的約束，自行引入的架構實現原則，是在高層次以上對需求、約束、和原則的理解和把握。 非功能性需求也可以稱為品質屬性，我所瞭解的非功能性需求主要有： 效能：回應時間或延遲 延展性：更多使用者，請求和資料的處理能力 可用性：99.9%意味著每天一分鐘故障 安全性：

首先參考： git tutorial git 簡易教程（足夠日常使用了）–by 廖雪峰 git遠程操作 – by 阮一峰 1. git 基礎概念 workspace / working directory：工作區 就是你在電腦裡能看到的目錄 index / stage：暫存區 更改通過git add到了這裡 repository：版本庫 git commit更改到這裡 （之前三個概念可參照工作區、暫存區 和 版本庫） remote

轉：https://github.com/xingshaocheng/architect-awesome 資料結構 隊列 集合 鏈表、數組 字典、關聯陣列 樹 二叉樹 完全二叉樹 平衡二叉樹 紅/黑樹狀結構 B-，B+，B*樹 常用演算法 排序、尋找演算法

時光退回到七八年以前，那個時候“架構師“還是一個很“高大上“的title。可是在今天的互連網圈，隨便一個工作了三、五年的開發人員，都可以稱之為架構師。 隨便多翻幾個招聘網站，你可以看到：前端架構師、後端架構師、Android架構師、iOS架構師、php架構師、營運架構師、DB架構師、搜尋結構描述師、中介軟體架構師、大資料架構師。。。五花八門，不一而足。