Ordering是Guava類庫提供的一個(gè)犀利強(qiáng)大的比較器工具,Guava的Ordering和JDK Comparator相比功能更強(qiáng)。它非常容易擴(kuò)展,可以輕松構(gòu)造復(fù)雜的comparator,然后用在容器的比較、排序等操作中。
本質(zhì)上來說,Ordering 實(shí)例無非就是一個(gè)特殊的Comparator 實(shí)例。Ordering只是需要依賴于一個(gè)比較器(例如,Collections.max)的方法,并使其可作為實(shí)例方法。另外,Ordering提供了鏈?zhǔn)椒椒ㄕ{(diào)用和加強(qiáng)現(xiàn)有的比較器。
下面我們看看Ordering中的一些具體方法和簡單的使用實(shí)例。
常見的靜態(tài)方法:
natural():使用Comparable類型的自然順序, 例如:整數(shù)從小到大,字符串是按字典順序;
usingToString() :使用toString()返回的字符串按字典順序進(jìn)行排序;
arbitrary() :返回一個(gè)所有對象的任意順序, 即compare(a, b) == 0 就是 a == b (identity equality)。 本身的排序是沒有任何含義, 但是在VM的生命周期是一個(gè)常量。
簡單實(shí)例:
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(): 返回與當(dāng)前Ordering相反的排序:
nullsFirst(): 返回一個(gè)將null放在non-null元素之前的Ordering,其他的和原始的Ordering一樣;
nullsLast():返回一個(gè)將null放在non-null元素之后的Ordering,其他的和原始的Ordering一樣;
compound(Comparator):返回一個(gè)使用Comparator的Ordering,Comparator作為第二排序元素,例如對bug列表進(jìn)行排序,先根據(jù)bug的級別,再根據(jù)優(yōu)先級進(jìn)行排序;
lexicographical():返回一個(gè)按照字典元素迭代的Ordering;
onResultOf(Function):將function應(yīng)用在各個(gè)元素上之后, 在使用原始o(jì)rdering進(jìn)行排序;
greatestOf(Iterable iterable, int k):返回指定的第k個(gè)可迭代的最大的元素,按照這個(gè)從最大到最小的順序。是不穩(wěn)定的。
leastOf(Iterable<E> iterable,int k):返回指定的第k個(gè)可迭代的最小的元素,按照這個(gè)從最小到最大的順序。是不穩(wěn)定的。
isOrdered(Iterable):是否有序,Iterable不能少于2個(gè)元素。
isStrictlyOrdered(Iterable):是否嚴(yán)格有序。請注意,Iterable不能少于兩個(gè)元素。
sortedCopy(Iterable):返回指定的元素作為一個(gè)列表的排序副本。
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]
轉(zhuǎn)自:http://singo107.iteye.com/blog/1175084
數(shù)據(jù)庫事務(wù)的隔離級別有4個(gè),由低到高依次為Read uncommitted 、Read committed 、Repeatable read 、Serializable ,這四個(gè)級別可以逐個(gè)解決臟讀 、不可重復(fù)讀 、幻讀 這幾類問題。
√: 可能出現(xiàn) ×: 不會(huì)出現(xiàn)
臟讀 | 不可重復(fù)讀 | 幻讀 | |
Read uncommitted | √ | √ | √ |
Read committed | × | √ | √ |
Repeatable read | × | × | √ |
Serializable | × | × | × |
注意:我們討論隔離級別的場景,主要是在多個(gè)事務(wù)并發(fā) 的情況下,因此,接下來的講解都圍繞事務(wù)并發(fā)。
公司發(fā)工資了,領(lǐng)導(dǎo)把5000元打到singo的賬號上,但是該事務(wù)并未提交,而singo正好去查看賬戶,發(fā)現(xiàn)工資已經(jīng)到賬,是5000元整,非常高 興。可是不幸的是,領(lǐng)導(dǎo)發(fā)現(xiàn)發(fā)給singo的工資金額不對,是2000元,于是迅速回滾了事務(wù),修改金額后,將事務(wù)提交,最后singo實(shí)際的工資只有 2000元,singo空歡喜一場。
出現(xiàn)上述情況,即我們所說的臟讀 ,兩個(gè)并發(fā)的事務(wù),“事務(wù)A:領(lǐng)導(dǎo)給singo發(fā)工資”、“事務(wù)B:singo查詢工資賬戶”,事務(wù)B讀取了事務(wù)A尚未提交的數(shù)據(jù)。
當(dāng)隔離級別設(shè)置為Read uncommitted 時(shí),就可能出現(xiàn)臟讀,如何避免臟讀,請看下一個(gè)隔離級別。
singo拿著工資卡去消費(fèi),系統(tǒng)讀取到卡里確實(shí)有2000元,而此時(shí)她的老婆也正好在網(wǎng)上轉(zhuǎn)賬,把singo工資卡的2000元轉(zhuǎn)到另一賬戶,并在 singo之前提交了事務(wù),當(dāng)singo扣款時(shí),系統(tǒng)檢查到singo的工資卡已經(jīng)沒有錢,扣款失敗,singo十分納悶,明明卡里有錢,為 何......
出現(xiàn)上述情況,即我們所說的不可重復(fù)讀 ,兩個(gè)并發(fā)的事務(wù),“事務(wù)A:singo消費(fèi)”、“事務(wù)B:singo的老婆網(wǎng)上轉(zhuǎn)賬”,事務(wù)A事先讀取了數(shù)據(jù),事務(wù)B緊接了更新了數(shù)據(jù),并提交了事務(wù),而事務(wù)A再次讀取該數(shù)據(jù)時(shí),數(shù)據(jù)已經(jīng)發(fā)生了改變。
當(dāng)隔離級別設(shè)置為Read committed 時(shí),避免了臟讀,但是可能會(huì)造成不可重復(fù)讀。
大多數(shù)數(shù)據(jù)庫的默認(rèn)級別就是Read committed,比如Sql Server , Oracle。如何解決不可重復(fù)讀這一問題,請看下一個(gè)隔離級別。
當(dāng)隔離級別設(shè)置為Repeatable read 時(shí),可以避免不可重復(fù)讀。當(dāng)singo拿著工資卡去消費(fèi)時(shí),一旦系統(tǒng)開始讀取工資卡信息(即事務(wù)開始),singo的老婆就不可能對該記錄進(jìn)行修改,也就是singo的老婆不能在此時(shí)轉(zhuǎn)賬。
雖然Repeatable read避免了不可重復(fù)讀,但還有可能出現(xiàn)幻讀 。
singo的老婆工作在銀行部門,她時(shí)常通過銀行內(nèi)部系統(tǒng)查看singo的信用卡消費(fèi)記錄。有一天,她正在查詢到singo當(dāng)月信用卡的總消費(fèi)金額 (select sum(amount) from transaction where month = 本月)為80元,而singo此時(shí)正好在外面胡吃海塞后在收銀臺買單,消費(fèi)1000元,即新增了一條1000元的消費(fèi)記錄(insert transaction ... ),并提交了事務(wù),隨后singo的老婆將singo當(dāng)月信用卡消費(fèi)的明細(xì)打印到A4紙上,卻發(fā)現(xiàn)消費(fèi)總額為1080元,singo的老婆很詫異,以為出 現(xiàn)了幻覺,幻讀就這樣產(chǎn)生了。
注:Mysql的默認(rèn)隔離級別就是Repeatable read。
Serializable 是最高的事務(wù)隔離級別,同時(shí)代價(jià)也花費(fèi)最高,性能很低,一般很少使用,在該級別下,事務(wù)順序執(zhí)行,不僅可以避免臟讀、不可重復(fù)讀,還避免了幻像讀。
Google是一個(gè)非常優(yōu)秀的公司。他們做出了很多令人稱贊的東西—既是公司外部,人們可以看到的東西,也是公司內(nèi)部。有一些在公司內(nèi)部并不屬于保密的事情,在外部并沒有給予足夠廣泛的討論。這就是我今天要說的。
讓Google的程序如此優(yōu)秀的一個(gè)最重要的事情看起來是非常的簡單:代碼審查。并不是只有Google做這個(gè)事情—代碼審查已經(jīng)被廣泛的認(rèn)可為一種非常好的做法,很多人都在這樣做。但我還沒有看到第二家這樣大的公司能把這種事情運(yùn)用的如此普遍。在Google,沒有程序,任何產(chǎn)品、任何項(xiàng)目的程序代碼,可以在沒有經(jīng)過有效的代碼審查前提交到代碼庫里的。
所有人都要經(jīng)過代碼審查。并且很正規(guī)的:這種事情應(yīng)該成為任何重要的軟件開發(fā)工作中一個(gè)基本制度。并不單指產(chǎn)品程序——所有東西。它不需要很多的工作,但它的效果是巨大的。
從代碼審查里能得到什么?
很顯然:在代碼提交前,用第二群眼睛檢查一遍,防止bug混入。這是對其最常見的理解,是對代碼審查的好處的最廣泛的認(rèn)識。但是,依我的經(jīng)驗(yàn)來看,這反倒是它最不重要的一點(diǎn)。人們確實(shí)在代碼審查中找到了bug。可是,這些在代碼審查中能發(fā)現(xiàn)的絕大部分bug,很顯然,都是微不足道的bug,程序的作者花幾分鐘的時(shí)間就能發(fā)現(xiàn)它們。真正需要花時(shí)間去發(fā)現(xiàn)的bug不是在代碼審查里能找到的。
代碼審查的最大的功用是純社會(huì)性的。如果你在編程,而且知道將會(huì)有同事檢查你的代碼,你編程態(tài)度就完全不一樣了。你寫出的代碼將更加整潔,有更好的注釋,更好的程序結(jié)構(gòu)——因?yàn)槟?strong style="border: 0px; margin: 0px; padding: 0px; vertical-align: baseline; background: transparent;">知道,那個(gè)你很在意的人將會(huì)查看你的程序。沒有代碼審查,你知道人們最終還是會(huì)看你的程序。但這種事情不是立即發(fā)生的事,它不會(huì)給你帶來同等的緊迫感,它不會(huì)給你相同的個(gè)人評判的那種感受。
還有一個(gè)非常重要的好處。代碼審查能傳播知識。在很多的開發(fā)團(tuán)隊(duì)里,經(jīng)常每一個(gè)人負(fù)責(zé)一個(gè)核心模塊,每個(gè)人都只關(guān)注他自己的那個(gè)模塊。除非是同事的模塊影響了自己的程序,他們從不相互交流。這種情況的后果是,每個(gè)模塊只有一個(gè)人熟悉里面的代碼。如果這個(gè)人休假或——但愿不是——辭職了,其他人則束手無策。通過代碼審查,至少會(huì)有兩個(gè)人熟悉這些程序——作者,以及審查者。審查者并不能像程序的作者一樣對程序十分了解——但他會(huì)熟悉程序的設(shè)計(jì)和架構(gòu),這是極其重要的。
當(dāng)然,沒有什么事情能簡單的做下來的。依我的經(jīng)驗(yàn),在你能正確的進(jìn)行代碼審查前,你需要花時(shí)間鍛煉學(xué)習(xí)。我發(fā)現(xiàn)人們在代碼審查時(shí)經(jīng)常會(huì)犯一些錯(cuò)誤,導(dǎo)致不少麻煩——尤其在一些缺乏經(jīng)驗(yàn)的審查者中經(jīng)常的出現(xiàn),他們給了人們一個(gè)很遭的代碼審查的體驗(yàn),成為了人們接受代碼審查制度的一個(gè)障礙。
最重要的一個(gè)原則:代碼審查用意是在代碼提交前找到其中的問題——你要發(fā)現(xiàn)是它的正確。在代碼審查中最常犯的錯(cuò)誤——幾乎每個(gè)新手都會(huì)犯的錯(cuò)誤——是,審查者根據(jù)自己的編程習(xí)慣來評判別人的代碼。
對于一個(gè)問題,通常我們能找出十幾種方法去解決。對于一種解決方案,我們能有百萬種編碼方案來實(shí)現(xiàn)它。作為一個(gè)審查者,你的任務(wù)不是來確保被審查的代碼都采用的是你的編碼風(fēng)格——因?yàn)樗豢赡芨銓懙囊粯印W鳛橐欢未a的審查者的任務(wù)是確保由作者自己寫出的代碼是正確的。一旦這個(gè)原則被打破,你最終將會(huì)倍感折磨,深受挫折——這可不是我們想要的結(jié)果。
問題在于,這種錯(cuò)誤是如此的普遍而易犯。如果你是個(gè)程序員,當(dāng)你遇到一個(gè)問題,你能想到一種解決方案——你就把你想到的方案作為標(biāo)準(zhǔn)答案。但事情不是這樣的——作為一個(gè)好的審查者,你需要明白這個(gè)道理。
代碼審查的第二個(gè)易犯的毛病是,人們覺得有壓力,感覺非要說點(diǎn)什么才好。你知道作者用了大量的時(shí)間和精力來實(shí)現(xiàn)這些程序——不該說點(diǎn)什么嗎?
不,你不需要。
只說一句“哇,不錯(cuò)呀”,任何時(shí)候都不會(huì)不合適。如果你總是力圖找出一點(diǎn)什么東西來批評,你這樣做的結(jié)果只會(huì)損害自己的威望。當(dāng)你不厭其煩的找出一些東西來,只是為了說些什么,被審查人就會(huì)知道,你說這些話只是為了填補(bǔ)寂靜。你的評論將不再被人重視。
第三是速度。你不能匆匆忙忙的進(jìn)行一次代碼審查——但你也要能迅速的完成。你的同伴在等你。如果你和你的同事并不想花太多時(shí)間進(jìn)行代碼復(fù)查,你們很快的完成,那被審查者會(huì)覺得很沮喪,這種代碼審查帶來的只有失望的感覺。就好象是打攪了大家,使大家放下手頭的工作來進(jìn)行審查。事情不該是這樣。你并不需要推掉手頭上的任何事情來做代碼審查。但如果中途耽誤了幾個(gè)小時(shí),你中間還要休息一會(huì),喝杯茶,沖個(gè)澡,或談會(huì)兒閑話。當(dāng)你回到審查現(xiàn)場,你可以繼續(xù)下去,把事情做完。如果你真是這樣,我想沒有人愿意在那干等著你。
wps只有32位的,因此要安裝wps必須安裝32位的支持庫,按照網(wǎng)上的教程先安裝32位的一些依賴庫基于云的應(yīng)用與運(yùn)行在私有數(shù)據(jù)中心的應(yīng)用之間最大的差別就是可擴(kuò)展性。云提供了按需擴(kuò)展的能力,能夠根據(jù)負(fù)載的波動(dòng)對應(yīng)用進(jìn)行擴(kuò)展和收縮。但是傳統(tǒng)應(yīng)用要充分發(fā)揮云的優(yōu)勢,并不是簡單地將應(yīng)用部署到云上就萬事大吉,而是需要根據(jù)云的特點(diǎn)圍繞可擴(kuò)展性重新進(jìn)行架構(gòu)設(shè)計(jì),近日AppDynamics的開發(fā)布道者Dustin.Whittle撰文闡述了適合云端部署的應(yīng)用架構(gòu),對我們傳統(tǒng)應(yīng)用往云端部署有很大的啟發(fā)和借鑒意義。
Dustin.Whittle給出了云應(yīng)用的示例架構(gòu),它具有高度的可擴(kuò)展性,如下圖所示:
在這個(gè)圖中,應(yīng)用按照分層的理念進(jìn)行了拆分,分別介紹如下:
客戶端層:客戶端層包含了針對目標(biāo)平臺的用戶界面,可能會(huì)包括基于Web的、移動(dòng)端的甚至是胖客戶端的用戶界面。一般來講,這可能會(huì)是Web應(yīng)用,包含諸如用戶管理、會(huì)話管理、頁面構(gòu)建等功能,但是其他客戶端所發(fā)起的交互都需要以RESTful服務(wù)的形式調(diào)用服務(wù)器。
服務(wù):服務(wù)器包含了緩存服務(wù)以及聚合(aggregate)服務(wù),其中緩存服務(wù)中持有記錄系統(tǒng)(system of record)中最新的已知狀態(tài),而聚集服務(wù)會(huì)直接與記錄系統(tǒng)交互,并且會(huì)執(zhí)行一些破壞性的操作(會(huì)改變記錄系統(tǒng)中的狀態(tài))。
記錄系統(tǒng):記錄系統(tǒng)是領(lǐng)域特定的服務(wù)端,它會(huì)驅(qū)動(dòng)業(yè)務(wù)功能,可能會(huì)包括客戶管理系統(tǒng)、采購系統(tǒng)、預(yù)定系統(tǒng)等等,這些很可能是遺留系統(tǒng),你的應(yīng)用需要與其進(jìn)行交互。聚集服務(wù)要負(fù)責(zé)將你的應(yīng)用從這些特有的記錄系統(tǒng)中抽象出來,并為你的應(yīng)用提供一致的前端接口。
ESB:當(dāng)記錄系統(tǒng)發(fā)生數(shù)據(jù)變化的時(shí)候,它需要觸發(fā)到指定主題(topic)的事件,這就是事件驅(qū)動(dòng)架構(gòu)(event-driven architecture,EDA)能夠影響應(yīng)用的地方了:當(dāng)記錄系統(tǒng)進(jìn)行了一項(xiàng)其他系統(tǒng)可能感興趣的變更時(shí),它會(huì)觸發(fā)一個(gè)事件,任何關(guān)注記錄系統(tǒng)的其他系統(tǒng)會(huì)監(jiān)聽到這個(gè)事件,并作出對應(yīng)的響應(yīng)。這也是使用使用主題(topic)而不是隊(duì)列(queue)的原因:隊(duì)列支持點(diǎn)對點(diǎn)(point-to-point)的消息,而主題支持發(fā)布-訂閱(publish-subscribe)的消息或事件。當(dāng)與遺留系統(tǒng)進(jìn)行集成時(shí),我們很期望這些遺留的系統(tǒng)能夠免遭負(fù)載的影響。因此,我們實(shí)現(xiàn)了一個(gè)緩存系統(tǒng),這個(gè)緩存系統(tǒng)維持了記錄系統(tǒng)中所有最新的已知狀態(tài)。緩存系統(tǒng)會(huì)使用EDA的規(guī)則監(jiān)聽記錄系統(tǒng)的變化,它會(huì)更新自己所保存數(shù)據(jù)的版本,從而保證與記錄系統(tǒng)中的數(shù)據(jù)相匹配。這是一個(gè)很強(qiáng)大的策略,不過會(huì)將一致性模型變?yōu)樽罱K一致性,也就是說如果你在社交媒體上發(fā)布一條狀態(tài)的話,你的朋友可能在幾秒鐘甚至幾分鐘之后才能看到,數(shù)據(jù)最終是一致的,但有時(shí)你所看到的與你的朋友所看到的并不一致。如果能接受這種一致性的話,就能在很大程度上實(shí)現(xiàn)可擴(kuò)展性的收益。
NoSQL:在數(shù)據(jù)存儲方面,有很多的可選方案,但如果要存儲大量數(shù)據(jù)的話,使用NoSQL存儲能夠更容易地?cái)U(kuò)展。有多種NoSQL存儲可供選擇,不過這要匹配所存儲數(shù)據(jù)的特點(diǎn),如MongoDB適合存儲可搜索的數(shù)據(jù),Neo4j適合存儲高度互相關(guān)聯(lián)的數(shù)據(jù),而Cassandra適合存儲鍵/值對,像Solr這樣的搜索索引有利于加速對經(jīng)常訪問數(shù)據(jù)的查詢。
將應(yīng)用拆分為多個(gè)層的時(shí)候,最好的模式就是使用面向服務(wù)架構(gòu)(service-oriented architecture,SOA)。要實(shí)現(xiàn)這一點(diǎn),可以使用SOAP,也可以使用REST,但是REST更為合適,因?yàn)樗蓴U(kuò)展性更強(qiáng)。作者接下來對REST的理念進(jìn)行了深入的闡述,InfoQ上關(guān)于REST已有很多相關(guān)的文章,如這里和這里,甚至包括Roy Fielding經(jīng)典博士論文的中譯本,所以這里不再贅述。不過,作者在這里特別強(qiáng)調(diào)了RESTful Web服務(wù)能夠保持無狀態(tài)性(stateless)。無狀態(tài)是實(shí)現(xiàn)可擴(kuò)展性的關(guān)鍵需求,因?yàn)闊o狀態(tài),所以請求可以由任何一個(gè)服務(wù)器響應(yīng)。如果你在服務(wù)層上需要更多的容量時(shí),只需要為該層添加虛擬機(jī)即可,而不需關(guān)注客戶端狀態(tài)保持的問題,負(fù)載可以很容易地重新分配。
前面介紹了基于云的應(yīng)用架構(gòu),接下來作者闡述了這樣的應(yīng)用該如何部署到云端。
RESTful Web服務(wù)要部署到Web容器中,并且要位于數(shù)據(jù)存儲之前。這些Web服務(wù)是沒有狀態(tài)的,只會(huì)反映其暴露的底層數(shù)據(jù)的狀態(tài),因此可以根據(jù)需要部署任意數(shù)量的服務(wù)器。在基于云的部署中,開始時(shí)可以開啟足夠的實(shí)例以應(yīng)對日常的需求,然后配置彈性策略,從而根據(jù)負(fù)載增加或減少服務(wù)器的數(shù)量。衡量飽和度的最好指標(biāo)就是服務(wù)的響應(yīng)時(shí)間。另外還需要考慮這些服務(wù)所使用的底層數(shù)據(jù)存儲的性能。示例的部署圖如下所示:
如果在云部署時(shí)有EDA的需求,那么就需要部署ESB,作者給出的建議是根據(jù)功能對ESB進(jìn)行分區(qū)(partitioning),這樣一個(gè)segment的過大負(fù)載不會(huì)影響到其他的segment。如下圖所示:
這種分離使System 1的負(fù)載與System 2的負(fù)載實(shí)現(xiàn)了隔離。如果System 1產(chǎn)生的負(fù)載拖慢了ESB,它只會(huì)影響到自己的segment,并不會(huì)影響到System 2的segment,因?yàn)樗渴鹪谄渌布稀H绻鸈SB產(chǎn)品支持的話,我們還可以給指定的segment添加服務(wù)器來實(shí)現(xiàn)擴(kuò)展。
基于云的應(yīng)用與傳統(tǒng)應(yīng)用有著很大的差別,因?yàn)樗兄煌臄U(kuò)展性需求。基于云的應(yīng)用必須有足夠的彈性以應(yīng)對服務(wù)器的添加與移除,必須松耦合,必須盡可能的無狀態(tài),必須預(yù)先規(guī)劃失敗的情況,并且必須能夠從幾臺服務(wù)器擴(kuò)展到成千上萬臺服務(wù)器。
針對云應(yīng)用并沒有唯一正確的架構(gòu),但是本文所闡述的RESTful服務(wù)以及事件驅(qū)動(dòng)架構(gòu)卻是經(jīng)過實(shí)踐檢驗(yàn)有效的架構(gòu)。作者認(rèn)為REST和EDA是實(shí)現(xiàn)云端可擴(kuò)展應(yīng)用的基本工具。
目前,國內(nèi)許多傳統(tǒng)的軟件廠商正在逐漸往云端遷移,希望本文所闡述的架構(gòu)理念能夠?yàn)樽x者提供一些借鑒。
from:http://www.douban.com/group/topic/35067110/mosquito 是一個(gè)MQTT 服務(wù)器。MQTT協(xié)議可用來做Android消息推送,服務(wù)器端采用mosquito+PhpMQTTClient(這個(gè)php用來做實(shí)驗(yàn))
自己不會(huì)java,不會(huì)Android開發(fā),推送的開發(fā)部分是同事做的。使用情況表明,單臺服務(wù)器能滿足幾萬的穩(wěn)定的連接數(shù),擴(kuò)展起來也不難,加機(jī)器即可。
下載最新版的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
如果當(dāng)前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補(bǔ)全,四個(gè)命令
mosquitto mosquitto_passwd mosquitto_pub mosquitto_sub
mosquitto服務(wù)器主程序,實(shí)現(xiàn)了MQTT協(xié)議
mosquitto_pub mosquitto發(fā)布消息的命令行程序
mosquitto_sub mosquitto訂閱消息的命令行程序
默認(rèn)的配置文件在 /etc/mosquitto/里
將/usr/local/mosquitto/lib/添加至/etc/ld.so.conf
執(zhí)行 ldconfig -f /etc/ld.so.conf 可能需要等待數(shù)秒
啟動(dòng)
mosquitto (-d后臺啟動(dòng))
可能提示沒有用戶 mosquitto,useradd mosquitto
終端測試
客戶端 mosquitto_sub -h 192.168.1.230 -t test
另起命令行mosquitto_pub -t test -m ’123′
PhpMQTTClient安裝
去https://github.com/tokudu/PhpMQTTClient 下載程序包,放置到服務(wù)器目錄
可能需要結(jié)合實(shí)際情況,要修改的地方
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;
啟動(dòng)mosquitto在前臺運(yùn)行,以方便獲取連接客戶端的信息
mosquitto
在服務(wù)器另外一終端上啟動(dòng)訂閱消息的進(jìn)程,訂閱所有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已經(jīng)安裝配置成功
解決mosquitto占有cpu進(jìn)程過高的問題 https://answers.launchpad.net/mosquitto/+question/189612
ulimit -u 4096
ulimit -n 4096
附:
配置文件
# =================================================================
# General configuration
# =================================================================
# 客戶端心跳的間隔時(shí)間
#retry_interval 20
# 系統(tǒng)狀態(tài)的刷新時(shí)間
#sys_interval 10
# 系統(tǒng)資源的回收時(shí)間,0表示盡快處理
#store_clean_interval 10
# 服務(wù)進(jìn)程的PID
#pid_file /var/run/mosquitto.pid
# 服務(wù)進(jìn)程的系統(tǒng)用戶
#user mosquitto
# 客戶端心跳消息的最大并發(fā)數(shù)
#max_inflight_messages 10
# 客戶端心跳消息緩存隊(duì)列
#max_queued_messages 100
# 用于設(shè)置客戶端長連接的過期時(shí)間,默認(rèn)永不過期
#persistent_client_expiration
# =================================================================
# Default listener
# =================================================================
# 服務(wù)綁定的IP地址
#bind_address
# 服務(wù)綁定的端口號
#port 1883
# 允許的最大連接數(shù),-1表示沒有限制
#max_connections -1
# cafile:CA證書文件
# capath:CA證書目錄
# certfile:PEM證書文件
# keyfile:PEM密鑰文件
#cafile
#capath
#certfile
#keyfile
# 必須提供證書以保證數(shù)據(jù)安全性
#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
# =================================================================
# 消息自動(dòng)保存的間隔時(shí)間
#autosave_interval 1800
# 消息自動(dòng)保存功能的開關(guān)
#autosave_on_changes false
# 持久化功能的開關(guān)
persistence true
# 持久化DB文件
#persistence_file mosquitto.db
# 持久化DB文件目錄
#persistence_location /var/lib/mosquitto/
# =================================================================
# Logging
# =================================================================
# 4種日志模式:stdout、stderr、syslog、topic
# none 則表示不記日志,此配置可以提升些許性能
log_dest none
# 選擇日志的級別(可設(shè)置多項(xiàng))
#log_type error
#log_type warning
#log_type notice
#log_type information
# 是否記錄客戶端連接信息
#connection_messages true
# 是否記錄日志時(shí)間
#log_timestamp true
# =================================================================
# Security
# =================================================================
# 客戶端ID的前綴限制,可用于保證安全性
#clientid_prefixes
# 允許匿名用戶
#allow_anonymous true
# 用戶/密碼文件,默認(rèn)格式:username:password
#password_file
# PSK格式密碼文件,默認(rèn)格式:identity:key
#psk_file
# pattern write sensor/%u/data
# ACL權(quán)限配置,常用語法如下:
# 用戶限制:user <username>
# 話題限制:topic [read|write] <topic>
# 正則限制:pattern write sensor/%u/data
#acl_file
# =================================================================
# Bridges
# =================================================================
# 允許服務(wù)之間使用“橋接”模式(可用于分布式部署)
#connection <name>
#address <host>[:<port>]
#topic <topic> [[[out | in | both] qos-level] local-prefix remote-prefix]
# 設(shè)置橋接的客戶端ID
#clientid
# 橋接斷開時(shí),是否清除遠(yuǎn)程服務(wù)器中的消息
#cleansession false
# 是否發(fā)布橋接的狀態(tài)信息
#notifications true
# 設(shè)置橋接模式下,消息將會(huì)發(fā)布到的話題地址
# $SYS/broker/connection/<clientid>/state
#notification_topic
# 設(shè)置橋接的keepalive數(shù)值
#keepalive_interval 60
# 橋接模式,目前有三種:automatic、lazy、once
#start_type automatic
# 橋接模式automatic的超時(shí)時(shí)間
#restart_timeout 30
# 橋接模式lazy的超時(shí)時(shí)間
#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 我愛小貝” 博客,請務(wù)必保留此出處http://cswei.blog.51cto.com/3443978/1225617
TDDL動(dòng)態(tài)數(shù)據(jù)源主要分為2層,每一層都實(shí)現(xiàn)了jdbc規(guī)范,以方便地集成到各種orm框架或者直接使用.每一層都各司其職.
整體結(jié)構(gòu)如上圖,TGroupDataSource(tddl group ds)默認(rèn)情況下依賴TAtomDataSource(tddl atom ds),但是可以擴(kuò)展依賴普通數(shù)據(jù)源.這一層主要的職責(zé)是解決讀寫分離以及主備切換的問題,當(dāng)然是在線執(zhí)行這些動(dòng)作,無需重啟.一個(gè)TGroupDataSource底下會(huì)掛多個(gè)TAtomDataSource,每個(gè)TAtomDataSource都有相對應(yīng)的讀寫權(quán)重.
TAtomDataSource(tddl atom ds)這一層并沒有實(shí)現(xiàn)真正的數(shù)據(jù)源邏輯,而是依賴了一個(gè)近似第三方的包-我們從jboss剝離出來的datasource,這一層的職責(zé)主要是將單個(gè)數(shù)據(jù)源的配置放置到diamond服務(wù)器中,實(shí)現(xiàn)數(shù)據(jù)源配置的集中管理和動(dòng)態(tài)變更.減少運(yùn)維成本. TAtomDataSource實(shí)際對應(yīng)了一個(gè)真正的數(shù)據(jù)源.
Tddl動(dòng)態(tài)數(shù)據(jù)源暫時(shí)支持mysql和oracle ,但是因?yàn)槊恳粚佣际莏dbc的實(shí)現(xiàn),所以很容易擴(kuò)展支持其他實(shí)現(xiàn)jdbc規(guī)范的數(shù)據(jù)源.
(1) 主備數(shù)據(jù)庫動(dòng)態(tài)容災(zāi)切換
支持進(jìn)行主備的對調(diào)切換,狀態(tài)對調(diào)后備庫變?yōu)橹鲙欤鲙熳優(yōu)閭鋷?/p>
(2) 相同數(shù)據(jù)分片讀寫分離
針對mysql replication機(jī)制進(jìn)行的數(shù)據(jù)主備復(fù)制,可以直接使用group datasource來支持讀寫分離。讀寫分離支持權(quán)重設(shè)置,允許對不同庫使用不同的權(quán)重。
(3) 讀重試
一臺數(shù)據(jù)庫掛掉后,如果是個(gè)fatal exception(有定義),那么會(huì)進(jìn)入讀重試,以確保盡可能多的數(shù)據(jù)訪問可以在正常數(shù)據(jù)庫中訪問。
(4) 數(shù)據(jù)庫掛掉排除,單線程重試
使用try – lock機(jī)制來進(jìn)行線程保護(hù),在第一次捕捉到fatal exception以后,只允許一個(gè)線程進(jìn)入數(shù)據(jù)庫進(jìn)行數(shù)據(jù)訪問,直到數(shù)據(jù)庫可以正常的工作為止
(5) 流量控制,數(shù)據(jù)庫保護(hù)
(1) 指定數(shù)據(jù)庫訪問(ThreadLocal)
一組對等數(shù)據(jù)庫中,寫庫一般只配置一個(gè),其余數(shù)據(jù)庫都為備庫,因?yàn)橥ㄟ^復(fù)制機(jī)制,所以主備主鍵有延遲,對于各種類型的讀(實(shí)時(shí)讀和延遲讀),可以使用GroupDataSourceRouteHelper.executeByGroupDataSourceIndex(int dataSourceIndex)指定需要訪問的數(shù)據(jù)庫.
(2) 指定數(shù)據(jù)庫訪問(Hint)
這是指定數(shù)據(jù)庫訪問的另外一種方式. 這種方式是在sql之前加注釋,告知tddl動(dòng)態(tài)數(shù)據(jù)源該選擇第幾個(gè)數(shù)據(jù)庫.類似: /*+TDDL_GROUP({groupIndex:0})*/select * from normaltbl_0001 where pk = ? 變幻groupIndex的數(shù)字即可指定具體的第幾個(gè)庫,從0開始.
(1) 數(shù)據(jù)源配置集中管控
(2) 定期密碼變更
(3) Jboss數(shù)據(jù)源連接池的配置管理和推送
(1) 動(dòng)態(tài)創(chuàng)建,添加,減少數(shù)據(jù)源
(2) 數(shù)據(jù)庫R,W,NA狀態(tài)通知,以及讀寫訪問控制,如置為NA則數(shù)據(jù)庫所有訪問會(huì)直接拋出SQLException
(3) 數(shù)據(jù)庫保護(hù)
Tddl的動(dòng)態(tài)數(shù)據(jù)源配置都放置在diamond配置中心,而一條diamond配置包括一個(gè)全局唯一的dataId和GROUP, tddl的配置數(shù)據(jù)也不例外,以下主要說明tddl動(dòng)態(tài)數(shù)據(jù)源的dataId拼寫以及每一個(gè)dataId下數(shù)據(jù)的內(nèi)容.(詳細(xì)示例請參考示例使用說明文檔)
Group中的配置主要是配置一組對等的數(shù)據(jù)的讀寫權(quán)重
dataId組成規(guī)范:“com.taobao.tddl.jdbc.group_V2.4.1_”+dbGroupKey
配置內(nèi)容(示例):tddl_sample_0:r10w10p0,tddl_sample_0_bac:r10w0p0
其中tddl_sample_0和tddl_sample_0_bak就是下一層需要的dbKey,后面r為讀權(quán)重,w為寫權(quán)重
atom ds中的配置分為了3部分(global,app,user),配置內(nèi)容全部為java的properties格式
Global
dataId組成規(guī)范: “com.taobao.tddl.atom.global.”+dbKey
配置內(nèi)容:
屬性key | 說明 |
ip | 數(shù)據(jù)實(shí)例的ip |
port | 數(shù)據(jù)實(shí)例的端口 |
dbname | 數(shù)據(jù)庫名稱 |
dbType | MYSQL,ORACLE |
dbStatus | RW,NA |
App
dataId組成規(guī)范: “com.taobao.tddl.atom.app.”+appName+”.”+dbKey
配置內(nèi)容:
屬性key | 說明 |
username | 該應(yīng)用使用的用戶名 |
oracleConType | oci,thin,如果db為mysql,則不用理會(huì) |
minPoolSize | 最小連接池 |
maxPoolSize | 最大連接池 |
idleTimeout | 連接的最大空閑時(shí)間 |
blockingTimeout | 等待連接的最大時(shí)間 |
preparedStatementCacheSize | Oracle專用 |
writeRestrictTimes | 單位timeSliceInMillis寫限制,默認(rèn)空不限制 |
readRestrictTimes | 單位timeSliceInMillis讀限制,默認(rèn)空不限制 |
threadCountRestrict | 并發(fā)線程限制,默認(rèn)空不限制 |
timeSliceInMillis | 限制的時(shí)間單位 |
connectionProperties | 連接參數(shù) |
User
dataId組成規(guī)范: “com.taobao.tddl.atom.passwd.”+dbName+”.”+dbType+”.”+userName
配置內(nèi)容:
屬性key | 說明 |
encPasswd | 密碼 |
encKey | 密鑰 |
Facebook 正式宣布開源 Presto —— 數(shù)據(jù)查詢引擎,可對250PB以上的數(shù)據(jù)進(jìn)行快速地交互式分析。該項(xiàng)目始于 2012 年秋季開始開發(fā),目前該項(xiàng)目已經(jīng)在超過 1000 名 Facebook 雇員中使用,運(yùn)行超過 30000 個(gè)查詢,每日數(shù)據(jù)在 1PB 級別。Facebook 稱 Presto 的性能比諸如 Hive 和 Map*Reduce 要好上 10 倍有多。
Presto 當(dāng)前支持 ANSI SQL 的大多數(shù)特效,包括聯(lián)合查詢、左右聯(lián)接、子查詢以及一些聚合和計(jì)算函數(shù);支持近似截然不同的計(jì)數(shù)(DISTINCT COUNT)等。
你可以通過下面地址了解該項(xiàng)目詳情和獲取代碼:
原文鏈接:http://www.oschina.net/news/45706/facebook-open-sources-presto-homegrown-sql-query-engine
摘要: 一款功能強(qiáng)大且實(shí)用的開發(fā)工具可以為開發(fā)者簡化開發(fā)流程,提高工作效率,允許開發(fā)者在應(yīng)用開發(fā)本身投入更多的時(shí)間和精力,從而提高作品質(zhì)量。本文就為大家分享4款實(shí)用的Android應(yīng)用架構(gòu)工具。 閱讀全文 摘要: 首先先介紹一款知名的網(wǎng)站壓力測試工具:webbench.Webbench能測試處在相同硬件上,不同服務(wù)的性能以及不同硬件上同一個(gè)服務(wù)的運(yùn)行狀況。webbench的標(biāo)準(zhǔn)測試可以向我們展示服務(wù)器的兩項(xiàng)內(nèi)容:每分鐘相應(yīng)請求數(shù)和每秒鐘傳輸數(shù)據(jù)量。webbench不但能具有便準(zhǔn)靜態(tài)頁面的測試能力,還能對動(dòng)態(tài)頁面(ASP,PHP,JAVA,CGI)進(jìn) 行測試的能力。還有就是他支持對含有SSL的安全網(wǎng)站例如電子... 閱讀全文