【正文】 使用客戶端去連接 Cassandra 其中的某一個(gè)節(jié)點(diǎn)然后存放讀取數(shù)據(jù) 了 首先需要定義 Cassandra 的服務(wù)端信息（只列出一些比較關(guān)鍵屬性）例如 cluster_name： Cassandra 集群名字。在一個(gè)集群里，負(fù)責(zé)把 行根據(jù) Key 分配到節(jié)點(diǎn)上。默認(rèn) 類是 SimpleSeedProvider，需要以逗號(hào)為分隔的節(jié)點(diǎn)信息 Seeds:節(jié)點(diǎn) IP 地址，作為 Cassandra 與外界交互的連接點(diǎn)。集群中所有的服務(wù)器在啟動(dòng)的時(shí)候，都將于 seed 節(jié)點(diǎn)進(jìn)行通信，從而獲取集群的相關(guān)信息。就如第二章介紹 ， KeySpace有點(diǎn)類似于數(shù)據(jù)庫 Schema,而 Cassandra 里所有操作都是基于 KeySpace，不同KeySpace 數(shù)據(jù)也是不同的。當(dāng) Cassandra 啟動(dòng)后，就可以利用上下文獲取 KeySpace 的，這樣就可以使用這個(gè) KeySpace 而獲取數(shù)據(jù)了。邏輯和 JavaJDBC非常接近 這樣，當(dāng)后臺(tái)數(shù)據(jù)處理管理器收集完數(shù)據(jù)后，會(huì)把數(shù)據(jù)保存到數(shù)據(jù)庫中，同時(shí)會(huì)把那些使用比較頻繁的數(shù)據(jù)保存到 Cassandra 中去，為了加快系統(tǒng)的查詢速度，建立了不同 ColumnFamily。 根據(jù)以上代碼， Cassandra主要根據(jù) KeySpace 和 ColumnFamily 中的 Key 進(jìn)行查詢 。如果系統(tǒng)中需要重新實(shí)現(xiàn)一個(gè)新的查詢，只需簡單 創(chuàng)建一個(gè) ColumnFamily，并用唯一 Key 去標(biāo)示就可以 系統(tǒng)會(huì)構(gòu)建出一個(gè)基于客戶賬號(hào) ID 查詢，其中客戶賬號(hào) ID 為 Key，而ColumnFamily 則是其所有的不同產(chǎn)品 交易信息。這 樣，系統(tǒng)在查詢生產(chǎn)數(shù)據(jù)的時(shí)候不必每次都從數(shù)據(jù)庫中查詢 在使用 Cassandra 過程中，為加快系統(tǒng)查詢速度，往往會(huì)建立很多冗余數(shù)據(jù)，其實(shí)很多數(shù)據(jù)都是類似甚至一樣的。所以，在系統(tǒng)的開發(fā)中，一般會(huì)根據(jù)以下原則去決定是否需要建立新的查詢呢（ ColumnFamily）。這種做法是把查詢的壓力轉(zhuǎn)換到了更新的操作上了，因?yàn)楫?dāng)數(shù)據(jù)變動(dòng)時(shí)， Cassandra 內(nèi)的數(shù)據(jù)也必須更新。這樣 Cassandra 就解決了系統(tǒng)中大數(shù)據(jù)量頻繁查詢問題 傳輸 在用戶查詢完數(shù)據(jù)后，對(duì)交易數(shù)據(jù)的傳輸是系統(tǒng)中又一比較重要的功能。在引入 Cassandra 后，當(dāng)系統(tǒng)接收到計(jì)算請(qǐng)求后，只需要把數(shù)據(jù)信息傳輸?shù)?Cassandra 里并生成唯一的運(yùn)算標(biāo)示符傳遞給計(jì)算引擎， 計(jì)算引擎會(huì)根據(jù)這個(gè)標(biāo)示符從 Cassandra 中讀取需要的數(shù)據(jù)，同樣在結(jié)果的處理和報(bào)表服務(wù)中也只需要從 Cassandra 中讀取就可以了。這樣Cassandra 的存在著實(shí)解決了前文所描述的系統(tǒng) V1 版本中 問題 如 所描述 ，首先需要使用 Cassandra 服務(wù)器并建立連接，然后可以簡單 實(shí)現(xiàn)把數(shù)據(jù)保存在 Cassandra 里，實(shí)現(xiàn)數(shù)據(jù)的傳輸 示例代碼會(huì)將數(shù)據(jù)保存到 Cassandra 的 KeySpace 里 這里首先根據(jù) KeySpace 準(zhǔn)備好一個(gè)類似與 Connection 的客戶端，然后使用withRow()定位一行，其中 columnFamilyDefinition 是 ColumnFamily 的定義，domainQueryCacheKey 是 ColumnFamily 的 Key,最后使用 putColumn 把一條數(shù)據(jù)放入 Cassandra 內(nèi) 這樣就實(shí)現(xiàn)了使用 Cassandra 作為中間的媒介進(jìn)行數(shù)據(jù)傳輸。最后后臺(tái)計(jì)算引擎會(huì)根據(jù)這個(gè) ID 從 Cassandra 中取出相關(guān)的數(shù)據(jù)，然后進(jìn)行計(jì)算，隨后把計(jì)算出來的結(jié)果也保存在 Cassandra 中。通過線程池的原理接受不同的計(jì)算請(qǐng)求然后發(fā)送給不同的接收者，不僅如此依然采用多線程 Future 處理返回的結(jié)果集，進(jìn)一步提高了計(jì)算速度 設(shè)計(jì) 驗(yàn)證模塊 的輸入是用戶自定義的模擬交易數(shù)據(jù)，經(jīng)過不同驗(yàn)證規(guī)則的驗(yàn)證，輸出則是驗(yàn)證報(bào)表。代碼中存在著過多的ifelse。目前驗(yàn)證模塊的主要需求是基于以下幾點(diǎn) 1 驗(yàn)證的級(jí)別。 Hard 警告表示數(shù)據(jù)的錯(cuò)誤致命的 ,用戶必須對(duì)數(shù)據(jù)進(jìn)行相應(yīng)的修改，否則無法進(jìn)行下一步操作。這些警告將以報(bào)表形式通知用戶 2 產(chǎn)品的多樣化。將來有可能需要提供給用戶自定義驗(yàn)證規(guī)則的頁面。這些將來的需求都要在目前的設(shè)計(jì)中加以考慮，其中有一個(gè)難點(diǎn)，就是如何保存這些動(dòng)態(tài)修改的數(shù)據(jù)以及 如何同步修改后的數(shù)據(jù) 根據(jù)對(duì) V1 版本的研究，目前的結(jié)構(gòu)已然不適 合目前的需求和將來的變動(dòng)，所以驗(yàn)證模塊的重構(gòu)勢在必行。VaREligibleService 是驗(yàn)證的接口，在實(shí)現(xiàn)中定義了某個(gè)產(chǎn)品類型和相關(guān)命令鏈的映射 VaRCommandMap，每一條命令鏈都會(huì)服務(wù)于某一個(gè)特定的產(chǎn)品并將驗(yàn)證的結(jié)果返回給接口并放到一個(gè)結(jié)果映射集中，最終解析這個(gè)結(jié)果映射集生成驗(yàn)證報(bào)告。這里可以 得出，驗(yàn)證需要遍歷輸入數(shù)據(jù)源然后等待每一筆數(shù)據(jù)的結(jié)果，時(shí)間比較長；因?yàn)橛簿幋a的問題，使得產(chǎn)品驗(yàn)證的規(guī)則難以維護(hù)，無法抽象出通用的驗(yàn)證規(guī)則，基本無法實(shí)現(xiàn)數(shù)據(jù)驗(yàn)證規(guī)則的動(dòng)態(tài)修改 根據(jù)系統(tǒng)要求和業(yè)務(wù)需求，對(duì)系統(tǒng)中 驗(yàn)證模塊進(jìn)行了重構(gòu)。 Spring 表達(dá)式語言是一個(gè)功能強(qiáng)大的表達(dá)式語言，它支持在運(yùn)行時(shí)查詢和操縱的對(duì)象圖。首先會(huì)定義一個(gè)模板類（ FilterTemplate） ,把所有產(chǎn)品驗(yàn)證規(guī)則抽象出來，做集中處理。 Build 類，每一個(gè)產(chǎn)品都會(huì)有一個(gè)Build 類，里面會(huì)定義其需要的所有驗(yàn)證規(guī)則，有效值以及錯(cuò)誤提示消息，規(guī)則 8 的定義必須與 Template 里定義的互相匹配。這里的思路基本是在 Annotation 基礎(chǔ)上，定義一套驗(yàn)證機(jī)制，針對(duì)不同 驗(yàn)證建立一系列內(nèi)置的驗(yàn)證規(guī)則，通過 JAXBAnnotation 轉(zhuǎn)成 XML 格式保存在數(shù)據(jù)庫中，同時(shí)針對(duì)不同產(chǎn)品的有效值、驗(yàn)證值也根據(jù)產(chǎn)品對(duì)象上的 Annotation，通過JAXBAnnotation 轉(zhuǎn)成產(chǎn)品的樣板。在進(jìn)行驗(yàn)證處理的時(shí)候，會(huì)把每一個(gè)產(chǎn)品的驗(yàn)證規(guī)則（ XML）和模板進(jìn)行匹配，最終解析成 SpringSPEL 表達(dá)式進(jìn)行處理。對(duì)于動(dòng)態(tài)修改驗(yàn)證規(guī)則，則是通過直接修改數(shù)據(jù)庫值并放到 Cassandra 內(nèi)來做到的，在引入 Cassandra 后， Cassandra會(huì)根據(jù)不同的策略進(jìn)行數(shù)據(jù)同步。這樣設(shè)計(jì)的好處在于：驗(yàn)證規(guī)則集中化，便于管理；產(chǎn)品特定的規(guī)則邏輯獨(dú)立，互相沒有依賴；規(guī)則命名規(guī)范統(tǒng)一；數(shù)據(jù)規(guī)則最終保存在數(shù)據(jù)庫內(nèi)，拋棄了代碼級(jí)別的規(guī)則定義，便于動(dòng)態(tài)更改； Cassandra 的使用則加快了運(yùn)行速度，以及正常驗(yàn)證處理和動(dòng)態(tài)改動(dòng)之間的隔離 重構(gòu)后的驗(yàn)證模塊， ValidationService 是驗(yàn)證邏輯的入口，主要負(fù)責(zé)對(duì)輸入交易數(shù)據(jù)進(jìn)行分類，根據(jù)交易產(chǎn)品的類型，將交易數(shù)據(jù)放置在一個(gè) Map 對(duì)象內(nèi)。使用了一個(gè)線程池概念，線程池大小目前定義為產(chǎn)品種類的數(shù)量，線程定義為實(shí)現(xiàn) Callable 接口 ,目的是為獲取返回值。調(diào)用 submit 方法提交驗(yàn)證任務(wù)，其中使用ValidationProcess 根據(jù) Build 和 FilterTemplate 互相協(xié)作生成出最終的返回值。在驗(yàn)證過程中把不同的產(chǎn)品放置在不 9