Ordering是Guava類庫提供的一個犀利強大的比較器工具,Guava的Ordering和JDK Comparator相比功能更強。它非常容易擴展,可以輕松構造復雜的comparator,然后用在容器的比較、排序等操作中。
本質上來說,Ordering 實例無非就是一個特殊的Comparator 實例。Ordering只是需要依賴于一個比較器(例如,Collections.max)的方法,并使其可作為實例方法。另外,Ordering提供了鏈式方法調用和加強現有的比較器。
下面我們看看Ordering中的一些具體方法和簡單的使用實例。
常見的靜態方法:
natural():使用Comparable類型的自然順序, 例如:整數從小到大,字符串是按字典順序;
usingToString() :使用toString()返回的字符串按字典順序進行排序;
arbitrary() :返回一個所有對象的任意順序, 即compare(a, b) == 0 就是 a == b (identity equality)。 本身的排序是沒有任何含義, 但是在VM的生命周期是一個常量。
簡單實例:
import java.util.List; import org.junit.Test; import com.google.common.collect.Lists; import com.google.common.collect.Ordering; public class OrderingTest { @Test public void testStaticOrdering(){ List<String> list = Lists.newArrayList(); list.add("peida"); list.add("jerry"); list.add("harry"); list.add("eva"); list.add("jhon"); list.add("neron"); System.out.println("list:"+ list);
Ordering<String> naturalOrdering = Ordering.natural(); Ordering<Object> usingToStringOrdering = Ordering.usingToString(); Ordering<Object> arbitraryOrdering = Ordering.arbitrary(); System.out.println("naturalOrdering:"+ naturalOrdering.sortedCopy(list)); System.out.println("usingToStringOrdering:"+ usingToStringOrdering.sortedCopy(list)); System.out.println("arbitraryOrdering:"+ arbitraryOrdering.sortedCopy(list)); } }
輸出:
list:[peida, jerry, harry, eva, jhon, neron]
naturalOrdering:[eva, harry, jerry, jhon, neron, peida]
usingToStringOrdering:[eva, harry, jerry, jhon, neron, peida]
arbitraryOrdering:[neron, harry, eva, jerry, peida, jhon]
操作方法:
reverse(): 返回與當前Ordering相反的排序:
nullsFirst(): 返回一個將null放在non-null元素之前的Ordering,其他的和原始的Ordering一樣;
nullsLast():返回一個將null放在non-null元素之后的Ordering,其他的和原始的Ordering一樣;
compound(Comparator):返回一個使用Comparator的Ordering,Comparator作為第二排序元素,例如對bug列表進行排序,先根據bug的級別,再根據優先級進行排序;
lexicographical():返回一個按照字典元素迭代的Ordering;
onResultOf(Function):將function應用在各個元素上之后, 在使用原始ordering進行排序;
greatestOf(Iterable iterable, int k):返回指定的第k個可迭代的最大的元素,按照這個從最大到最小的順序。是不穩定的。
leastOf(Iterable<E> iterable,int k):返回指定的第k個可迭代的最小的元素,按照這個從最小到最大的順序。是不穩定的。
isOrdered(Iterable):是否有序,Iterable不能少于2個元素。
isStrictlyOrdered(Iterable):是否嚴格有序。請注意,Iterable不能少于兩個元素。
sortedCopy(Iterable):返回指定的元素作為一個列表的排序副本。
package com.peidasoft.guava.base; import java.util.List; import org.junit.Test; import com.google.common.collect.ImmutableList; import com.google.common.collect.Lists; import com.google.common.collect.Ordering; public class OrderingTest { @Test public void testOrdering(){ List<String> list = Lists.newArrayList(); list.add("peida"); list.add("jerry"); list.add("harry"); list.add("eva"); list.add("jhon"); list.add("neron"); System.out.println("list:"+ list); Ordering<String> naturalOrdering = Ordering.natural(); System.out.println("naturalOrdering:"+ naturalOrdering.sortedCopy(list)); List<Integer> listReduce= Lists.newArrayList(); for(int i=9;i>0;i--){ listReduce.add(i); } List<Integer> listtest= Lists.newArrayList(); listtest.add(1); listtest.add(1); listtest.add(1); listtest.add(2); Ordering<Integer> naturalIntReduceOrdering = Ordering.natural(); System.out.println("listtest:"+ listtest); System.out.println(naturalIntReduceOrdering.isOrdered(listtest)); System.out.println(naturalIntReduceOrdering.isStrictlyOrdered(listtest)); System.out.println("naturalIntReduceOrdering:"+ naturalIntReduceOrdering.sortedCopy(listReduce)); System.out.println("listReduce:"+ listReduce); System.out.println(naturalIntReduceOrdering.isOrdered(naturalIntReduceOrdering.sortedCopy(listReduce))); System.out.println(naturalIntReduceOrdering.isStrictlyOrdered(naturalIntReduceOrdering.sortedCopy(listReduce))); Ordering<String> natural = Ordering.natural(); List<String> abc = ImmutableList.of("a", "b", "c"); System.out.println(natural.isOrdered(abc)); System.out.println(natural.isStrictlyOrdered(abc)); System.out.println("isOrdered reverse :"+ natural.reverse().isOrdered(abc)); List<String> cba = ImmutableList.of("c", "b", "a"); System.out.println(natural.isOrdered(cba)); System.out.println(natural.isStrictlyOrdered(cba)); System.out.println(cba = natural.sortedCopy(cba)); System.out.println("max:"+natural.max(cba)); System.out.println("min:"+natural.min(cba)); System.out.println("leastOf:"+natural.leastOf(cba, 2)); System.out.println("naturalOrdering:"+ naturalOrdering.sortedCopy(list)); System.out.println("leastOf list:"+naturalOrdering.leastOf(list, 3)); System.out.println("greatestOf:"+naturalOrdering.greatestOf(list, 3)); System.out.println("reverse list :"+ naturalOrdering.reverse().sortedCopy(list)); System.out.println("isOrdered list :"+ naturalOrdering.isOrdered(list)); System.out.println("isOrdered list :"+ naturalOrdering.reverse().isOrdered(list)); list.add(null); System.out.println(" add null list:"+list); System.out.println("nullsFirst list :"+ naturalOrdering.nullsFirst().sortedCopy(list)); System.out.println("nullsLast list :"+ naturalOrdering.nullsLast().sortedCopy(list)); } } //============輸出============== list:[peida, jerry, harry, eva, jhon, neron] naturalOrdering:[eva, harry, jerry, jhon, neron, peida] listtest:[1, 1, 1, 2] true false naturalIntReduceOrdering:[1, 2, 3, 4, 5, 6, 7, 8, 9] listReduce:[9, 8, 7, 6, 5, 4, 3, 2, 1] true true true true isOrdered reverse :false false false [a, b, c] max:c min:a leastOf:[a, b] naturalOrdering:[eva, harry, jerry, jhon, neron, peida] leastOf list:[eva, harry, jerry] greatestOf:[peida, neron, jhon] reverse list :[peida, neron, jhon, jerry, harry, eva] isOrdered list :false isOrdered list :false add null list:[peida, jerry, harry, eva, jhon, neron, null] nullsFirst list :[null, eva, harry, jerry, jhon, neron, peida] nullsLast list :[eva, harry, jerry, jhon, neron, peida, null]
轉自:http://singo107.iteye.com/blog/1175084
數據庫事務的隔離級別有4個,由低到高依次為Read uncommitted 、Read committed 、Repeatable read 、Serializable ,這四個級別可以逐個解決臟讀 、不可重復讀 、幻讀 這幾類問題。
√: 可能出現 ×: 不會出現
臟讀 | 不可重復讀 | 幻讀 | |
Read uncommitted | √ | √ | √ |
Read committed | × | √ | √ |
Repeatable read | × | × | √ |
Serializable | × | × | × |
注意:我們討論隔離級別的場景,主要是在多個事務并發 的情況下,因此,接下來的講解都圍繞事務并發。
公司發工資了,領導把5000元打到singo的賬號上,但是該事務并未提交,而singo正好去查看賬戶,發現工資已經到賬,是5000元整,非常高 興。可是不幸的是,領導發現發給singo的工資金額不對,是2000元,于是迅速回滾了事務,修改金額后,將事務提交,最后singo實際的工資只有 2000元,singo空歡喜一場。
出現上述情況,即我們所說的臟讀 ,兩個并發的事務,“事務A:領導給singo發工資”、“事務B:singo查詢工資賬戶”,事務B讀取了事務A尚未提交的數據。
當隔離級別設置為Read uncommitted 時,就可能出現臟讀,如何避免臟讀,請看下一個隔離級別。
singo拿著工資卡去消費,系統讀取到卡里確實有2000元,而此時她的老婆也正好在網上轉賬,把singo工資卡的2000元轉到另一賬戶,并在 singo之前提交了事務,當singo扣款時,系統檢查到singo的工資卡已經沒有錢,扣款失敗,singo十分納悶,明明卡里有錢,為 何......
出現上述情況,即我們所說的不可重復讀 ,兩個并發的事務,“事務A:singo消費”、“事務B:singo的老婆網上轉賬”,事務A事先讀取了數據,事務B緊接了更新了數據,并提交了事務,而事務A再次讀取該數據時,數據已經發生了改變。
當隔離級別設置為Read committed 時,避免了臟讀,但是可能會造成不可重復讀。
大多數數據庫的默認級別就是Read committed,比如Sql Server , Oracle。如何解決不可重復讀這一問題,請看下一個隔離級別。
當隔離級別設置為Repeatable read 時,可以避免不可重復讀。當singo拿著工資卡去消費時,一旦系統開始讀取工資卡信息(即事務開始),singo的老婆就不可能對該記錄進行修改,也就是singo的老婆不能在此時轉賬。
雖然Repeatable read避免了不可重復讀,但還有可能出現幻讀 。
singo的老婆工作在銀行部門,她時常通過銀行內部系統查看singo的信用卡消費記錄。有一天,她正在查詢到singo當月信用卡的總消費金額 (select sum(amount) from transaction where month = 本月)為80元,而singo此時正好在外面胡吃海塞后在收銀臺買單,消費1000元,即新增了一條1000元的消費記錄(insert transaction ... ),并提交了事務,隨后singo的老婆將singo當月信用卡消費的明細打印到A4紙上,卻發現消費總額為1080元,singo的老婆很詫異,以為出 現了幻覺,幻讀就這樣產生了。
注:Mysql的默認隔離級別就是Repeatable read。
Serializable 是最高的事務隔離級別,同時代價也花費最高,性能很低,一般很少使用,在該級別下,事務順序執行,不僅可以避免臟讀、不可重復讀,還避免了幻像讀。
Google是一個非常優秀的公司。他們做出了很多令人稱贊的東西—既是公司外部,人們可以看到的東西,也是公司內部。有一些在公司內部并不屬于保密的事情,在外部并沒有給予足夠廣泛的討論。這就是我今天要說的。
讓Google的程序如此優秀的一個最重要的事情看起來是非常的簡單:代碼審查。并不是只有Google做這個事情—代碼審查已經被廣泛的認可為一種非常好的做法,很多人都在這樣做。但我還沒有看到第二家這樣大的公司能把這種事情運用的如此普遍。在Google,沒有程序,任何產品、任何項目的程序代碼,可以在沒有經過有效的代碼審查前提交到代碼庫里的。
所有人都要經過代碼審查。并且很正規的:這種事情應該成為任何重要的軟件開發工作中一個基本制度。并不單指產品程序——所有東西。它不需要很多的工作,但它的效果是巨大的。
從代碼審查里能得到什么?
很顯然:在代碼提交前,用第二群眼睛檢查一遍,防止bug混入。這是對其最常見的理解,是對代碼審查的好處的最廣泛的認識。但是,依我的經驗來看,這反倒是它最不重要的一點。人們確實在代碼審查中找到了bug。可是,這些在代碼審查中能發現的絕大部分bug,很顯然,都是微不足道的bug,程序的作者花幾分鐘的時間就能發現它們。真正需要花時間去發現的bug不是在代碼審查里能找到的。
代碼審查的最大的功用是純社會性的。如果你在編程,而且知道將會有同事檢查你的代碼,你編程態度就完全不一樣了。你寫出的代碼將更加整潔,有更好的注釋,更好的程序結構——因為你知道,那個你很在意的人將會查看你的程序。沒有代碼審查,你知道人們最終還是會看你的程序。但這種事情不是立即發生的事,它不會給你帶來同等的緊迫感,它不會給你相同的個人評判的那種感受。
還有一個非常重要的好處。代碼審查能傳播知識。在很多的開發團隊里,經常每一個人負責一個核心模塊,每個人都只關注他自己的那個模塊。除非是同事的模塊影響了自己的程序,他們從不相互交流。這種情況的后果是,每個模塊只有一個人熟悉里面的代碼。如果這個人休假或——但愿不是——辭職了,其他人則束手無策。通過代碼審查,至少會有兩個人熟悉這些程序——作者,以及審查者。審查者并不能像程序的作者一樣對程序十分了解——但他會熟悉程序的設計和架構,這是極其重要的。
當然,沒有什么事情能簡單的做下來的。依我的經驗,在你能正確的進行代碼審查前,你需要花時間鍛煉學習。我發現人們在代碼審查時經常會犯一些錯誤,導致不少麻煩——尤其在一些缺乏經驗的審查者中經常的出現,他們給了人們一個很遭的代碼審查的體驗,成為了人們接受代碼審查制度的一個障礙。
最重要的一個原則:代碼審查用意是在代碼提交前找到其中的問題——你要發現是它的正確。在代碼審查中最常犯的錯誤——幾乎每個新手都會犯的錯誤——是,審查者根據自己的編程習慣來評判別人的代碼。
對于一個問題,通常我們能找出十幾種方法去解決。對于一種解決方案,我們能有百萬種編碼方案來實現它。作為一個審查者,你的任務不是來確保被審查的代碼都采用的是你的編碼風格——因為它不可能跟你寫的一樣。作為一段代碼的審查者的任務是確保由作者自己寫出的代碼是正確的。一旦這個原則被打破,你最終將會倍感折磨,深受挫折——這可不是我們想要的結果。
問題在于,這種錯誤是如此的普遍而易犯。如果你是個程序員,當你遇到一個問題,你能想到一種解決方案——你就把你想到的方案作為標準答案。但事情不是這樣的——作為一個好的審查者,你需要明白這個道理。
代碼審查的第二個易犯的毛病是,人們覺得有壓力,感覺非要說點什么才好。你知道作者用了大量的時間和精力來實現這些程序——不該說點什么嗎?
不,你不需要。
只說一句“哇,不錯呀”,任何時候都不會不合適。如果你總是力圖找出一點什么東西來批評,你這樣做的結果只會損害自己的威望。當你不厭其煩的找出一些東西來,只是為了說些什么,被審查人就會知道,你說這些話只是為了填補寂靜。你的評論將不再被人重視。
第三是速度。你不能匆匆忙忙的進行一次代碼審查——但你也要能迅速的完成。你的同伴在等你。如果你和你的同事并不想花太多時間進行代碼復查,你們很快的完成,那被審查者會覺得很沮喪,這種代碼審查帶來的只有失望的感覺。就好象是打攪了大家,使大家放下手頭的工作來進行審查。事情不該是這樣。你并不需要推掉手頭上的任何事情來做代碼審查。但如果中途耽誤了幾個小時,你中間還要休息一會,喝杯茶,沖個澡,或談會兒閑話。當你回到審查現場,你可以繼續下去,把事情做完。如果你真是這樣,我想沒有人愿意在那干等著你。
wps只有32位的,因此要安裝wps必須安裝32位的支持庫,按照網上的教程先安裝32位的一些依賴庫基于云的應用與運行在私有數據中心的應用之間最大的差別就是可擴展性。云提供了按需擴展的能力,能夠根據負載的波動對應用進行擴展和收縮。但是傳統應用要充分發揮云的優勢,并不是簡單地將應用部署到云上就萬事大吉,而是需要根據云的特點圍繞可擴展性重新進行架構設計,近日AppDynamics的開發布道者Dustin.Whittle撰文闡述了適合云端部署的應用架構,對我們傳統應用往云端部署有很大的啟發和借鑒意義。
Dustin.Whittle給出了云應用的示例架構,它具有高度的可擴展性,如下圖所示:
在這個圖中,應用按照分層的理念進行了拆分,分別介紹如下:
客戶端層:客戶端層包含了針對目標平臺的用戶界面,可能會包括基于Web的、移動端的甚至是胖客戶端的用戶界面。一般來講,這可能會是Web應用,包含諸如用戶管理、會話管理、頁面構建等功能,但是其他客戶端所發起的交互都需要以RESTful服務的形式調用服務器。
服務:服務器包含了緩存服務以及聚合(aggregate)服務,其中緩存服務中持有記錄系統(system of record)中最新的已知狀態,而聚集服務會直接與記錄系統交互,并且會執行一些破壞性的操作(會改變記錄系統中的狀態)。
記錄系統:記錄系統是領域特定的服務端,它會驅動業務功能,可能會包括客戶管理系統、采購系統、預定系統等等,這些很可能是遺留系統,你的應用需要與其進行交互。聚集服務要負責將你的應用從這些特有的記錄系統中抽象出來,并為你的應用提供一致的前端接口。
ESB:當記錄系統發生數據變化的時候,它需要觸發到指定主題(topic)的事件,這就是事件驅動架構(event-driven architecture,EDA)能夠影響應用的地方了:當記錄系統進行了一項其他系統可能感興趣的變更時,它會觸發一個事件,任何關注記錄系統的其他系統會監聽到這個事件,并作出對應的響應。這也是使用使用主題(topic)而不是隊列(queue)的原因:隊列支持點對點(point-to-point)的消息,而主題支持發布-訂閱(publish-subscribe)的消息或事件。當與遺留系統進行集成時,我們很期望這些遺留的系統能夠免遭負載的影響。因此,我們實現了一個緩存系統,這個緩存系統維持了記錄系統中所有最新的已知狀態。緩存系統會使用EDA的規則監聽記錄系統的變化,它會更新自己所保存數據的版本,從而保證與記錄系統中的數據相匹配。這是一個很強大的策略,不過會將一致性模型變為最終一致性,也就是說如果你在社交媒體上發布一條狀態的話,你的朋友可能在幾秒鐘甚至幾分鐘之后才能看到,數據最終是一致的,但有時你所看到的與你的朋友所看到的并不一致。如果能接受這種一致性的話,就能在很大程度上實現可擴展性的收益。
NoSQL:在數據存儲方面,有很多的可選方案,但如果要存儲大量數據的話,使用NoSQL存儲能夠更容易地擴展。有多種NoSQL存儲可供選擇,不過這要匹配所存儲數據的特點,如MongoDB適合存儲可搜索的數據,Neo4j適合存儲高度互相關聯的數據,而Cassandra適合存儲鍵/值對,像Solr這樣的搜索索引有利于加速對經常訪問數據的查詢。
將應用拆分為多個層的時候,最好的模式就是使用面向服務架構(service-oriented architecture,SOA)。要實現這一點,可以使用SOAP,也可以使用REST,但是REST更為合適,因為它可擴展性更強。作者接下來對REST的理念進行了深入的闡述,InfoQ上關于REST已有很多相關的文章,如這里和這里,甚至包括Roy Fielding經典博士論文的中譯本,所以這里不再贅述。不過,作者在這里特別強調了RESTful Web服務能夠保持無狀態性(stateless)。無狀態是實現可擴展性的關鍵需求,因為無狀態,所以請求可以由任何一個服務器響應。如果你在服務層上需要更多的容量時,只需要為該層添加虛擬機即可,而不需關注客戶端狀態保持的問題,負載可以很容易地重新分配。
前面介紹了基于云的應用架構,接下來作者闡述了這樣的應用該如何部署到云端。
RESTful Web服務要部署到Web容器中,并且要位于數據存儲之前。這些Web服務是沒有狀態的,只會反映其暴露的底層數據的狀態,因此可以根據需要部署任意數量的服務器。在基于云的部署中,開始時可以開啟足夠的實例以應對日常的需求,然后配置彈性策略,從而根據負載增加或減少服務器的數量。衡量飽和度的最好指標就是服務的響應時間。另外還需要考慮這些服務所使用的底層數據存儲的性能。示例的部署圖如下所示:
如果在云部署時有EDA的需求,那么就需要部署ESB,作者給出的建議是根據功能對ESB進行分區(partitioning),這樣一個segment的過大負載不會影響到其他的segment。如下圖所示:
這種分離使System 1的負載與System 2的負載實現了隔離。如果System 1產生的負載拖慢了ESB,它只會影響到自己的segment,并不會影響到System 2的segment,因為它部署在其他硬件上。如果ESB產品支持的話,我們還可以給指定的segment添加服務器來實現擴展。
基于云的應用與傳統應用有著很大的差別,因為它有著不同的擴展性需求。基于云的應用必須有足夠的彈性以應對服務器的添加與移除,必須松耦合,必須盡可能的無狀態,必須預先規劃失敗的情況,并且必須能夠從幾臺服務器擴展到成千上萬臺服務器。
針對云應用并沒有唯一正確的架構,但是本文所闡述的RESTful服務以及事件驅動架構卻是經過實踐檢驗有效的架構。作者認為REST和EDA是實現云端可擴展應用的基本工具。
目前,國內許多傳統的軟件廠商正在逐漸往云端遷移,希望本文所闡述的架構理念能夠為讀者提供一些借鑒。
from:http://www.douban.com/group/topic/35067110/mosquito 是一個MQTT 服務器。MQTT協議可用來做Android消息推送,服務器端采用mosquito+PhpMQTTClient(這個php用來做實驗)
自己不會java,不會Android開發,推送的開發部分是同事做的。使用情況表明,單臺服務器能滿足幾萬的穩定的連接數,擴展起來也不難,加機器即可。
下載最新版的mosquitto
cd /usr/local/src
wget http://mosquitto.org/files/source/mosquitto-1.1.2.tar.gz
tar zxvf mosquitto-1.1.2.tar.gz
cd mosquitto-1.1.2
如果當前openssl版本低于1.0,修改config.mk中的WITH_TLS_PSK:=no
make
make install prefix=/usr/local/mosquitto
為方便管理,添加下面至/etc/profile
export PATH=”$PATH:/usr/local/mosquitto/bin”
export PATH=”$PATH:/usr/local/mosquitto/sbin”
source /etc/profile
[root@mysql230 mosquitto]# mosquitto #tab補全,四個命令
mosquitto mosquitto_passwd mosquitto_pub mosquitto_sub
mosquitto服務器主程序,實現了MQTT協議
mosquitto_pub mosquitto發布消息的命令行程序
mosquitto_sub mosquitto訂閱消息的命令行程序
默認的配置文件在 /etc/mosquitto/里
將/usr/local/mosquitto/lib/添加至/etc/ld.so.conf
執行 ldconfig -f /etc/ld.so.conf 可能需要等待數秒
啟動
mosquitto (-d后臺啟動)
可能提示沒有用戶 mosquitto,useradd mosquitto
終端測試
客戶端 mosquitto_sub -h 192.168.1.230 -t test
另起命令行mosquitto_pub -t test -m ’123′
PhpMQTTClient安裝
去https://github.com/tokudu/PhpMQTTClient 下載程序包,放置到服務器目錄
可能需要結合實際情況,要修改的地方
index.php
$result = $conn->connect(SAM_MQTT, array(‘SAM_HOST’ => ’127.0.0.1′, ‘SAM_PORT’ => 1883));
SAM/MQTT/sam_mqtt.php
$this->port = 1883;
啟動mosquitto在前臺運行,以方便獲取連接客戶端的信息
mosquitto
在服務器另外一終端上啟動訂閱消息的進程,訂閱所有tokudu開頭topic
mosquitto_sub –t tokudu /+
注意,此處之所以要使用tokudu,可以看index.php的182行 var target = ‘tokudu/’ + $(‘#messageTarget’).val();
在mosquitto的終端獲得mosquitto_sub客戶端的id
1350006978: New client connected from 127.0.0.1 as mosqsub/8491-localhost..
訪問http://host:port/ ,push notification target字段填寫8491-localhost,push notification text填寫需要推送的測試消息
在mosquitto的終端查看是否收到了推送的消息,如果收到,說明phpmqttclient已經安裝配置成功
解決mosquitto占有cpu進程過高的問題 https://answers.launchpad.net/mosquitto/+question/189612
ulimit -u 4096
ulimit -n 4096
附:
配置文件
# =================================================================
# General configuration
# =================================================================
# 客戶端心跳的間隔時間
#retry_interval 20
# 系統狀態的刷新時間
#sys_interval 10
# 系統資源的回收時間,0表示盡快處理
#store_clean_interval 10
# 服務進程的PID
#pid_file /var/run/mosquitto.pid
# 服務進程的系統用戶
#user mosquitto
# 客戶端心跳消息的最大并發數
#max_inflight_messages 10
# 客戶端心跳消息緩存隊列
#max_queued_messages 100
# 用于設置客戶端長連接的過期時間,默認永不過期
#persistent_client_expiration
# =================================================================
# Default listener
# =================================================================
# 服務綁定的IP地址
#bind_address
# 服務綁定的端口號
#port 1883
# 允許的最大連接數,-1表示沒有限制
#max_connections -1
# cafile:CA證書文件
# capath:CA證書目錄
# certfile:PEM證書文件
# keyfile:PEM密鑰文件
#cafile
#capath
#certfile
#keyfile
# 必須提供證書以保證數據安全性
#require_certificate false
# 若require_certificate值為true,use_identity_as_username也必須為true
#use_identity_as_username false
# 啟用PSK(Pre-shared-key)支持
#psk_hint
# SSL/TSL加密算法,可以使用“openssl ciphers”命令獲取
# as the output of that command.
#ciphers
# =================================================================
# Persistence
# =================================================================
# 消息自動保存的間隔時間
#autosave_interval 1800
# 消息自動保存功能的開關
#autosave_on_changes false
# 持久化功能的開關
persistence true
# 持久化DB文件
#persistence_file mosquitto.db
# 持久化DB文件目錄
#persistence_location /var/lib/mosquitto/
# =================================================================
# Logging
# =================================================================
# 4種日志模式:stdout、stderr、syslog、topic
# none 則表示不記日志,此配置可以提升些許性能
log_dest none
# 選擇日志的級別(可設置多項)
#log_type error
#log_type warning
#log_type notice
#log_type information
# 是否記錄客戶端連接信息
#connection_messages true
# 是否記錄日志時間
#log_timestamp true
# =================================================================
# Security
# =================================================================
# 客戶端ID的前綴限制,可用于保證安全性
#clientid_prefixes
# 允許匿名用戶
#allow_anonymous true
# 用戶/密碼文件,默認格式:username:password
#password_file
# PSK格式密碼文件,默認格式:identity:key
#psk_file
# pattern write sensor/%u/data
# ACL權限配置,常用語法如下:
# 用戶限制:user <username>
# 話題限制:topic [read|write] <topic>
# 正則限制:pattern write sensor/%u/data
#acl_file
# =================================================================
# Bridges
# =================================================================
# 允許服務之間使用“橋接”模式(可用于分布式部署)
#connection <name>
#address <host>[:<port>]
#topic <topic> [[[out | in | both] qos-level] local-prefix remote-prefix]
# 設置橋接的客戶端ID
#clientid
# 橋接斷開時,是否清除遠程服務器中的消息
#cleansession false
# 是否發布橋接的狀態信息
#notifications true
# 設置橋接模式下,消息將會發布到的話題地址
# $SYS/broker/connection/<clientid>/state
#notification_topic
# 設置橋接的keepalive數值
#keepalive_interval 60
# 橋接模式,目前有三種:automatic、lazy、once
#start_type automatic
# 橋接模式automatic的超時時間
#restart_timeout 30
# 橋接模式lazy的超時時間
#idle_timeout 60
# 橋接客戶端的用戶名
#username
# 橋接客戶端的密碼
#password
# bridge_cafile:橋接客戶端的CA證書文件
# bridge_capath:橋接客戶端的CA證書目錄
# bridge_certfile:橋接客戶端的PEM證書文件
# bridge_keyfile:橋接客戶端的PEM密鑰文件
#bridge_cafile
#bridge_capath
#bridge_certfile
#bridge_keyfile
# 自己的配置可以放到以下目錄中
include_dir /etc/mosquitto/conf.d
本文出自 “Cooke Chen 我愛小貝” 博客,請務必保留此出處http://cswei.blog.51cto.com/3443978/1225617
TDDL動態數據源主要分為2層,每一層都實現了jdbc規范,以方便地集成到各種orm框架或者直接使用.每一層都各司其職.
整體結構如上圖,TGroupDataSource(tddl group ds)默認情況下依賴TAtomDataSource(tddl atom ds),但是可以擴展依賴普通數據源.這一層主要的職責是解決讀寫分離以及主備切換的問題,當然是在線執行這些動作,無需重啟.一個TGroupDataSource底下會掛多個TAtomDataSource,每個TAtomDataSource都有相對應的讀寫權重.
TAtomDataSource(tddl atom ds)這一層并沒有實現真正的數據源邏輯,而是依賴了一個近似第三方的包-我們從jboss剝離出來的datasource,這一層的職責主要是將單個數據源的配置放置到diamond服務器中,實現數據源配置的集中管理和動態變更.減少運維成本. TAtomDataSource實際對應了一個真正的數據源.
Tddl動態數據源暫時支持mysql和oracle ,但是因為每一層都是jdbc的實現,所以很容易擴展支持其他實現jdbc規范的數據源.
(1) 主備數據庫動態容災切換
支持進行主備的對調切換,狀態對調后備庫變為主庫,主庫變為備庫
(2) 相同數據分片讀寫分離
針對mysql replication機制進行的數據主備復制,可以直接使用group datasource來支持讀寫分離。讀寫分離支持權重設置,允許對不同庫使用不同的權重。
(3) 讀重試
一臺數據庫掛掉后,如果是個fatal exception(有定義),那么會進入讀重試,以確保盡可能多的數據訪問可以在正常數據庫中訪問。
(4) 數據庫掛掉排除,單線程重試
使用try – lock機制來進行線程保護,在第一次捕捉到fatal exception以后,只允許一個線程進入數據庫進行數據訪問,直到數據庫可以正常的工作為止
(5) 流量控制,數據庫保護
(1) 指定數據庫訪問(ThreadLocal)
一組對等數據庫中,寫庫一般只配置一個,其余數據庫都為備庫,因為通過復制機制,所以主備主鍵有延遲,對于各種類型的讀(實時讀和延遲讀),可以使用GroupDataSourceRouteHelper.executeByGroupDataSourceIndex(int dataSourceIndex)指定需要訪問的數據庫.
(2) 指定數據庫訪問(Hint)
這是指定數據庫訪問的另外一種方式. 這種方式是在sql之前加注釋,告知tddl動態數據源該選擇第幾個數據庫.類似: /*+TDDL_GROUP({groupIndex:0})*/select * from normaltbl_0001 where pk = ? 變幻groupIndex的數字即可指定具體的第幾個庫,從0開始.
(1) 數據源配置集中管控
(2) 定期密碼變更
(3) Jboss數據源連接池的配置管理和推送
(1) 動態創建,添加,減少數據源
(2) 數據庫R,W,NA狀態通知,以及讀寫訪問控制,如置為NA則數據庫所有訪問會直接拋出SQLException
(3) 數據庫保護
Tddl的動態數據源配置都放置在diamond配置中心,而一條diamond配置包括一個全局唯一的dataId和GROUP, tddl的配置數據也不例外,以下主要說明tddl動態數據源的dataId拼寫以及每一個dataId下數據的內容.(詳細示例請參考示例使用說明文檔)
Group中的配置主要是配置一組對等的數據的讀寫權重
dataId組成規范:“com.taobao.tddl.jdbc.group_V2.4.1_”+dbGroupKey
配置內容(示例):tddl_sample_0:r10w10p0,tddl_sample_0_bac:r10w0p0
其中tddl_sample_0和tddl_sample_0_bak就是下一層需要的dbKey,后面r為讀權重,w為寫權重
atom ds中的配置分為了3部分(global,app,user),配置內容全部為java的properties格式
Global
dataId組成規范: “com.taobao.tddl.atom.global.”+dbKey
配置內容:
屬性key | 說明 |
ip | 數據實例的ip |
port | 數據實例的端口 |
dbname | 數據庫名稱 |
dbType | MYSQL,ORACLE |
dbStatus | RW,NA |
App
dataId組成規范: “com.taobao.tddl.atom.app.”+appName+”.”+dbKey
配置內容:
屬性key | 說明 |
username | 該應用使用的用戶名 |
oracleConType | oci,thin,如果db為mysql,則不用理會 |
minPoolSize | 最小連接池 |
maxPoolSize | 最大連接池 |
idleTimeout | 連接的最大空閑時間 |
blockingTimeout | 等待連接的最大時間 |
preparedStatementCacheSize | Oracle專用 |
writeRestrictTimes | 單位timeSliceInMillis寫限制,默認空不限制 |
readRestrictTimes | 單位timeSliceInMillis讀限制,默認空不限制 |
threadCountRestrict | 并發線程限制,默認空不限制 |
timeSliceInMillis | 限制的時間單位 |
connectionProperties | 連接參數 |
User
dataId組成規范: “com.taobao.tddl.atom.passwd.”+dbName+”.”+dbType+”.”+userName
配置內容:
屬性key | 說明 |
encPasswd | 密碼 |
encKey | 密鑰 |