mycat實例（1）

2016 二月

22

置 原

MyCat - 使用篇（1）

分類：數據庫分庫分表（Mycat等）

（1126） （1）

數據庫路由中間件MyCat - 使用篇（1）

基本概念

直接介紹概念太枯燥了，還是拿個和背景篇相似的例子介紹
業務場景：客戶完成下單，快遞員接受並更新運單狀態，客戶可以隨時查看運單狀態的任務。一票快遞可能有多個子母件。同時，我們需要標記每個運單的狀態，運單狀態的解釋和含義保存在運單狀態字典表中。
因此，我們需要建立如下表：

我們現在按照業務將數據庫垂直拆分成運單庫（單表2000tps，6000W數據），快遞員庫（單表1500tps，100W數據），客戶庫（單表 1500tps，1000W數據記錄）；假設每個MySQL數據庫單表不能超過2000W數據，單表不能超過1000tps。那么運單庫則需要分成3片， 客戶庫需要分成2片，統一由MyCat管理。如下圖所示：

1.邏輯庫

MyCat作為一個中間件，對應用應為無感知的。
應用訪問MyCat，根據之前所述，應用感知到后台只是一個（或者多個，和訪問MySQL實例一樣）數據庫（假設只有一個數據庫，這個庫叫SF，里面有運單相關表，快遞員相關表和客戶相關表）；這里MyCat的數據庫就是邏輯庫。訪問MyCat，結果應該如下面所示

雖然其中的表可能存在於不同的庫，但是表面上，他們屬於同一個MyCat實例中的同一個邏輯庫。所以，雖然上面的架構圖顯示他們不在同一個數據庫，但是在MyCat中，他們在同一個邏輯庫。

2.邏輯表

在邏輯庫下的表就是邏輯表。邏輯表可以分片，也可以不分片。
orders表明顯是要分片的表，但是在MyCat看來，他們雖然分布在不同的分片節點上（分布在不同的MySQL數據庫上），但仍視為是同一個邏輯表，在同一個邏輯庫里。

2.1分片表

分片表，是指那些原有的很大數據的表，需要切分到多個數據庫的表，這樣，每個分片都有一部分數據，所有分片構成了完整的數據。分片表都有自己的分片規則，根據分片規則確定分片。
配置里面，如下配置：

<table name="orders" primaryKey="id" dataNode="test$1-2" rule="mod-long"> </table>

意思就是用mod-long規則根據主鍵id將運單表orders分割到test1，test2這兩個數據庫（分片節點）上。
請求情況1：

select * from orders where id = 1;

對於分片表的查詢，如果按照分片列查詢，則請求只會被發送到一個分片上。
請求情況2：

select * from orders where id < 100 and id > 0;

對於分片表的查詢，如果按照分片列范圍（在字段類型支持范圍的情況下）查詢，則請求會根據分片規則計算兩個邊界值，然后將請求發送到對應結果的分片上，並合並每個分片的結果。
請求情況3：

select * from orders where initialpoint = 'Beijing';

像這種根據非分片列查詢的情況，請求會被發送到所有分片上，並合並每個分片的結果。
請求情況4：
請求為更新類型的sql語句，與查詢的三種情況相同處理。

2.2 非分片表

一個數據庫中並不是所有的表都很大，某些表是可以不用進行切分的，非分片是相對分片表來說的，就是那些不需要進行數據切分的表。
例如：

<table name="courier" primaryKey="id" dataNode="test3"> </table>

意思就是快遞員表不用分片，保存在test3這個分片節點上。
對於非分片表的操作和對普通數據庫的一樣，因為不涉及到分布式數據庫。

2.3 ER表

關系型數據庫是基於實體關系模型（Entity-Relationship Model)之上，通過其描述了真實世界中事物與關系，Mycat中的ER表即是來源於此。根據這一思路，提出了基於E-R關系的數據分片策略，子表的記 錄與所關聯的父表記錄存放在同一個數據分片上，即子表依賴於父表，通過表分組（Table Group）保證數據Join不會跨庫操作。
表分組（Table Group）是解決跨分片數據join的一種很好的思路，也是數據切分規划的重要一條規則。
如下：

<!-- 運單表，對主鍵id對2取模 --> <table name="orders" primaryKey="id" dataNode="test$1-2" rule="mod-long"> <!-- 運單子母件表，運單表的子表，order_id與orders的id列對應 --> <childTable name="orders_cargo" joinKey="order_id" parentKey="id"> </childTable> </table>

運單表為分片表，運單表和運單子母件表為一對多關系，可以做成父子表。
對於子表的sql請求，都是通過joinKey對應到父表對應字段后，按照之前分片表的規則進行處理。

2.4 全局表

一個真實的業務系統中，往往存在大量的類似字典表的表，這些表基本上很少變動，字典表具有以下幾個特性：

• 變動不頻繁
• 數據量總體變化不大
• 數據規模不大，很少有超過數十萬條記錄。

對於這類的表，在分片的情況下，當業務表因為規模而進行分片以后，業務表與這些附屬的字典表之間的關聯，就成了比較棘手的問題，所以Mycat中通 過數據冗余來解決這類表的join，即所有的分片都有一份數據的拷貝，所有將字典表或者符合字典表特性的一些表定義為全局表。
數據冗余是解決跨分片數據join的一種很好的思路，也是數據切分規划的另外一條重要規則
比如：

<!-- 運單狀態信息表，公共表，放在和運單表同樣的分片上 --> <table name="order_status_interception" primaryKey="id" type="global" dataNode="test$1-2"> </table>

運單狀態信息字典表，只是注釋每種運單狀態，就是典型的字典表，與分片表orders為多對一的關系。
對於全局表，所有的查詢請求，只會發送到其中一個全局表分片上執行，所有的更新請求，會在每個全局表分片上執行。

2.5 如何決定？

根據之前的描述，我們可以推斷出，對於分片表的修改和查詢，如果是按照分片字段進行查找的話，則請求會被轉發到一個分片上。如果不是按照分片字段的 話，就會把請求發到每一個分片上進行查找。所以，分片字段的選擇比較重要！對於全局表，相當於在每個分片上有一份相同的復制，修改請求會在每一個分片上執 行，但是查詢只會落到一個分片上。所以，全局表盡量是不會改變的而且是需要和分片表做Join操作的，如果經常改變或者不需要做join，最好還是做成非 分片表。

先拋出了這幾種邏輯表的概念，大家先有個印象。現在我們結合具體實際討論如何決定表的類型。

首先，orders表可定是分片表。orders_cargo表是子母件表，一個order可能有多個子母件，所以，最好把orders_cargo作為orders的子表。
這種情況下，orders與orders_cargo按照對應鍵（就是子表按照哪個鍵與主表的哪個鍵對應進行分片。比如orders_cargo就是order_id與orders的id對應。這是以order_id與orders的id進行join結果就是對的）join結果也是正確的。

像這種簡單的從屬關系一對n的表，我們處理起來很簡單，一般將它們按照需要做join的鍵設為父子表即可。

但是下面的場景很麻煩，比如快遞員與運單就是多對多的關系，客戶對於運單也是多對多的關系（一個收方，一個寄方）。我們既有快遞員需要查看自己的所有運單的場景和客戶查看自己所有運單的場景。相對的，我們也有查看一個運單涉及到的快遞員還有客戶的場景。
customer表（客戶表）以及courier表（快遞員表）因為與分片表orders之間不做join操作，所以不用作為公共表。
首先，關系表可以作為公共表，這樣的話，涉及到與分片表的join操作沒有限制，因為在每個分片，公共表都是完整的。但是，關系表的更新很頻繁，我們可能不能忍受每更新一次關系表就跑到每個分片上都更新一次（性能，可靠性考慮）。
那么作為運單的子表呢？那么查找一個運單涉及到的快遞員還有客戶就比較簡單。因為根據運單號（也就是分片id）查詢，MyCat就會根據分片規則給他定位到具體分片，而不是去按分片搜索。

但是相應的，快遞員查看自己所有運單的場景就比較慢，因為請求是發送到每一個分片上查找。

作為快遞員的子表也有同樣的缺陷。
還有一種方法，就是這種關系表同時作為運單和快遞員的子表。但是這樣，目前需要應用自己去做雙寫。MyCat目前還沒實現這種。當然，我覺得這是一個我們自己可以根據需要改進的地方。MyCat中間件根據關系冗余表關系進行雙寫

另外，究竟取哪種方法，都是從業務出發去考慮的。在這里，如果從快遞員出發去查找以及從運單出發去查找的業務壓力差不多大的話，那么最好就采用關系 表同時作為運單和客戶的子表這種方法。然后將快遞員和運單的業務獨立，每個業務應用都去維護自己的關系表，同時通過消息隊列來保持關系表之間的一致性。這 樣也不失為一種方法。

 

 

 

2016 二月

23

置 原

MyCat - 使用篇（2）

分類：數據庫分庫分表（Mycat等）

（4673） （1）

數據庫路由中間件MyCat - 使用篇（2）

基本概念

3. 分片

3.1 分片節點（dataNode）

表被水平切分后，每個分片表所在的數據庫就是一個分片節點。一個分片節點對應一個數據庫（mysql數據庫）。一個分片節點只能保存每個分片表的一個分片，因為db中不允許出現同名的表。
例如：

<dataNode name="test1" dataHost="test" database="db1" />

這就表示，名字為test1這個分片節點，對應test節點主機（MySQL實例）主機上的db1數據庫

3.2 節點主機（dataHost）

分片節點究竟被放在那個主機上。對應mysql里的mysql實例：一台主機可以部署多個mysql實例，一個mysql實例可以有多個數據庫。為 了規避單節點主機並發數限制，盡量將讀寫壓力高的分片節點（dataNode）均衡的放在不同的節點主機（dataHost）.
例如：

<dataHost name="test" maxCon="1000" minCon="10" balance="0" writeType="0" dbType="mysql" dbDriver="native" switchType="-1" slaveThreshold="100"> <heartbeat>select 1 from dual</heartbeat> <writeHost host="master" url="10.202.4.181:3306" user="root" password="sf123456"> <readHost host="slave" url="10.202.4.181:3307" user="root" password="sf123456"/> </writeHost> </dataHost>

這個會在之后的配置文件說明中細講。

分片規則

就決定分片表的記錄如何分布在不同的分片節點上。分片規則有很多種，我們根據業務需要，並考慮到開發，維護以及擴容的難度，來決定用哪種分片方案。
分片規則一般還涉及到全局id生成，這個之后會講。
MyCat支持我們自己開發自己的分片規則，如何開發，我們后面會講到（以下規則最好不要照搬，參考之后並按照自己的需要開發自己的分片方案）：

1. 哈希取模：

這是最常見的一種分片方案，根據分片字段（一般是主鍵，因為按主鍵查找的場景偏多）的哈希值，對分片個數取模運算，根據結果決定記錄到哪個分片上。
一般分片個數最好為2的n次方，這樣計算起來可以用取與運算（x%(2^n)=x&(2^n - 1)）.
好處：記錄平均分布（除非id生成器故意生成取模正好只為同一個數的id），壓力平均分布，數據沒有傾斜
壞處：擴容（增加分片）是個大問題，分片個數改變，基本很難遷移數據
配置舉例：
rule.xml:

<tableRule name="mod-long-rule1"> <rule> <columns>user_id</columns> <algorithm>mod-long</algorithm> </rule> </tableRule> <function name="mod-long" class="org.opencloudb.route.function.PartitionByMod"> <!-- how many data nodes --> <property name="count">3</property> </function>

可以看出，用java反射機制加載org.opencloudb.route.function.PartitionByMod這個類，在這個 org.opencloudb.route.function的所有類都為分片算法，如何實現，將會在之后的rule.xml配置說明中提到。這個算法接 收一個參數，其實就是分片個數。之后在tableRule標簽中,規定是哪一列（字段）為分片字段，對應哪一算法。
在這里，就是用user_id對3取模之后的值作為該記錄分布在哪一個分片節點上。

2. 路由約定：

rule.xml:

<tableRule name="file-map-rule1"> <rule> <columns>address</columns> <algorithm>file-map</algorithm> </rule> </tableRule> <function name="file-map" class="org.opencloudb.route.function.PartitionByFileMap"> <property name="mapFile">partition-file-map.txt</property> <property name="type">1</property> <property name="defaultNode">0</property> </function>

type為零則字段類型為整型，為1則為字符串類型。維護一個對應表配置文件partition-file-map.txt，如下所示：
partition-file-map.txt：

北京=0 上海=1 深圳=2 廣州=2 default=3

意思就是分片字段為北京的到分片0上，上海的到分片1上，深圳和廣州的到分片2上，其他的到分片3上。
如果某天發現北京的分片需要擴容，可以將北京的數據整體遷移到一個更大的分片上，之后重載配置。MyCat支持在線重載配置
好處：擴容比較靈活
壞處：數據容易有傾斜，擴容不是很靈活，而且，分片字段很難是常用查詢字段（如果查詢字段不是分片字段，就是全分片檢索）

3.范圍路由約定：

也是維護一個文件，如下所示：

<tableRule name="auto-sharding-long"> <rule> <columns>user_id</columns> <algorithm>rang-long</algorithm> </rule> </tableRule> <function name="rang-long" class="org.opencloudb.route.function.AutoPartitionByLong"> <property name="mapFile">autopartition-long.txt</property> <property name="defaultNode">0</property> </function>

autopartition-long.txt

0~1000k=0 1000k~2000k=1 default=2

就是指分片字段在0~1000k范圍內的到分片0上。。。。。。
好處：保證每個分片數據穩定，擴容也比較方便
壞處：需要配合id生成器，否則按順序自增會有壓力集中在一個分片的問題。同時，擴容時同時要改變MyCat配置以及id生成器配置。及時做數據清理，id最好能復用，這個規則才能很好的應用。

4.哈希范圍約定：

將哈希取模與范圍路由結合。

<tableRule name="sharding-by-pattern"> <rule> <columns>user_id</columns> <algorithm>sharding-by-pattern</algorithm> </rule> </tableRule> <function name="sharding-by-pattern" class="org.opencloudb.route.function.PartitionByPattern"> <property name="patternValue">64</property> <property name="defaultNode">2</property> <property name="mapFile">partition-pattern.txt</property> </function>

0~15=0 16~31=1 32~47=2 48~63=3

哈希取模后范圍在0~15的流向分片1.。。。
這樣可以某種程度上減輕擴容的壓力。

5.部分字段：

有時候，我們並不想一個字段的所有內容都作為分片我們可以取某個字段的一部分作為分片依據。配合id生成器使用。

6.綜合約定（原創，非內置）：

其實，我們可以結合id生成器，做一種既好擴容，又維護不復雜，又能平均分攤壓力的方法。
參考百X的某些項目，他們是項目開始就建64個庫，每個庫64張表。假設每張表1000w數據，那么一共能承受409.6億的數據。。。從現在來看估計這個項目做到死也許都用不完。
不過這給我們一個思路，我們根據項目需要估計未來n年的量，在項目一開始就分配這么多庫。這些庫可能在項目初期位於同一個實例上。在不夠用時，我們把其中某幾個庫遷移到其他實例上。
我們可以讓id生成器去做平均分布的事情。
比如下面這個id：
01-01-XXXASD1239091234
我們用第一個-之前的數字直接作為分片id，我們為了考慮到以后的業務增長，一開始就分配了64個庫。id生成器先開始只會隨機平均生成00~03開頭的，之后業務增長到某個程度時，再按照需求多少在某個范圍生成。

7.多重規則-可擴容哈希路由（原創，非內置）

是從分片字段中抽取一段做分片路由，再取另一段做自動哈希分片。同時再規定某個范圍內是某個分片規則，另一范圍是另一個分片規則。
id示例：
北京-A0000001
配置文件：

北京（A0000000~A9999999）=0，1，2,3,4 北京（B0000000）=5,6,7,8,9 上海（00000000~10000000）=10,11 上海=10,11，12,13,14,15

意思就是，開頭為北京的范圍在A0000000~A9999999的根據后面的哈希值對5取模平均分布在0，1，2,3,4分片節點上。開頭為北京 的范圍在B0000000以上的根據后面的哈希值對5取模平均分布在5,6,7,8,9分片節點上。開頭為上海的范圍在 00000000~10000000的根據后面的哈希值對2取模平均分布在10,11分片節點上，剩下的開頭為上海的，對6取模平均分布在 10,11，12,13,14,15上。
這樣，在發現某個開頭的分片不夠用時，可以隨時改變分片規則，同時不影響以前數據的訪問。

2016 二月

23

置 原

MyCat - 使用篇（3）

分類：數據庫分庫分表（Mycat等）

（5478） （0）

數據庫路由中間件MyCat - 使用篇（3）

全局序列號

數據切分后，原有的關系數據庫中的主鍵約束在分布式條件下將無法使用，因此需要引入外部機制保證數據唯一性標識，這種保證全局性的數據唯一標識的機制就是全局序列號（sequence）。

1. 本地文件方式

classpath下有一個sequence_conf.properties文件：

GLOBAL_SEQ.HISIDS= GLOBAL_SEQ.MINID=1001 GLOBAL_SEQ.MAXID=1000000000 GLOBAL_SEQ.CURID=1000

HISIDS表示歷史使用過的值，MINID為ID最小值，MAXID為ID最大值，CURID為當前值。
需要在server.xml加入如下配置：

<system><property name="sequnceHandlerType">0</property></system>

sequnceHandlerType 需要配置為 0，表示使用本地文件配置。
使用示例：

insert into table1(id,name) values(next value for MYCATSEQ_GLOBAL,‘test’);

但是這么做，MyCat就不是無狀態中間件，很難去做MyCat集群。而且，這樣的id只是純數字。最后，每次MyCat重新發布，id恢復初始值。所以，不推薦這種用法。

2.數據庫方式

在數據庫中建立一張表，存放 sequence 名稱(name)，sequence 當前值(current_value)，步長(increment）每次讀取多少個 sequence，假設為 K)等信息；
server.xml：

<system><property name="sequnceHandlerType">1</property></system>

建表語句：

DROP TABLE IF EXISTS MYCAT_SEQUENCE; CREATE TABLE MYCAT_SEQUENCE (name VARCHAR(50) NOT NULL,current_value INT NOT NULL,increment INT NOT NULL DEFAULT 100, PRIMARY KEY(name)) ENGINE=InnoDB; INSERT INTO MYCAT_SEQUENCE(name,current_value,increment) VALUES (‘GLOBAL’, 100000, 100);

創建相關function:

DROP FUNCTION IF EXISTS mycat_seq_currval; DELIMITER CREATE FUNCTION mycat_seq_currval(seq_name VARCHAR(50)) RETURNS varchar(64) CHARSET utf-8 DETERMINISTIC BEGIN DECLARE retval VARCHAR(64); SET retval=“-999999999,null”; SELECT concat(CAST(current_value AS CHAR),“,”,CAST(increment AS CHAR)) INTO retval FROM MYCAT_SEQUENCE WHERE name = seq_name; RETURN retval; END DELIMITER; – 謳置 sequence 值 DROP FUNCTION IF EXISTS mycat_seq_setval; DELIMITER CREATE FUNCTION mycat_seq_setval(seq_name VARCHAR(50),value INTEGER) RETURNS varchar(64) CHARSET utf-8 DETERMINISTIC BEGIN UPDATE MYCAT_SEQUENCE SET current_value = value WHERE name = seq_name; RETURN mycat_seq_currval(seq_name); END DELIMITER; – 獲叏下一個 sequence 值 DROP FUNCTION IF EXISTS mycat_seq_nextval; DELIMITER CREATE FUNCTION mycat_seq_nextval(seq_name VARCHAR(50)) RETURNS varchar(64) CHARSET utf-8 DETERMINISTIC BEGIN UPDATE MYCAT_SEQUENCE SET current_value = current_value + increment WHERE name = seq_name; RETURN mycat_seq_currval(seq_name); END DELIMITER;

sequence_db_conf.properties指定 sequence 相關配置在哪個節點上

USER_SEQ=test_dn1

使用示例：

insert into table1(id,name) values(next value for MYCATSEQ_GLOBAL,‘test’);

這樣做雖然MyCat為無狀態而且id有持久化，並且一次可以取出多個id，通過配置可以有主從切換。但是，id還是純數字，沒有有意義的信息，而且，MyCat主從切換並不可靠，id生成有故障，則整個服務都無法正常進行，這在架構上有單點問題，是不推薦的。

3.本地時間戳方式

ID= 64 位二進制 (42(毫秒)+5(機器 ID)+5(業務編碼)+12(重復累加)
server.xml：

<system><property name="sequnceHandlerType">2</property></system>

sequence_time_conf.properties：

WORKID=0-31 任意整數 DATAACENTERID=0-31 任意整數

4.通過繼承或者重構相關類實現

修改源代碼，主要是和MyCATSequnceProcessor相關的類，定制自己的id。之后源代碼篇會講

但是全局序列號還是推薦用獨立的id生成器服務（獨立於MyCat的服務）去實現最佳！

安裝准備

環境

Red Hat Enterprise Linux Server release 6.6 (Santiago)
java version “1.7.0_79”

軟件

• zookeeper 3.4.6 （MyCat監控依賴於zookeeper，同時，MyCat1.5之后引入了zk的配置方式）
• MyCat 1.5GA（1.5版本已經比較穩定）:https://github.com/MyCATApache/Mycat-Server/
• MyCat-eye 1.0: https://github.com/MyCATApache/Mycat-Web 用來監控MyCat

配置並部署zookeeper

只要部署好即可，默認配置，將conf/zoo_sample.cfg 重命名為conf/zoo.cfg。啟動后驗證下即可（因為目前只為了為監控服務）

配置MyCat

下載MyCat的源代碼，並使用maven打包安裝：mvn install -Dmaven.test.skip=true. 使用生成的linux下的tar.gz文件，解壓。

1. 業務分析

接下來是我們的重點，MyCat的配置，還是拿之前的例子，我們只需要一個邏輯庫（schema1），運單庫則需要分成3片，客戶庫需要分成2片， 統一由MyCat管理。業務上，客戶和快遞員查詢和自己相關的運單比客戶和快遞員還有倉管員通過運單號查詢相關信息的業務量少的，所以以運單為中心進行分 片。

運單表根據運單號哈希取模分片；
運單子母件表作為運單表的子表；
快遞員運單關系表作為運單表的子表；
客戶運單關系表作為運單表的子表；
快遞員信息變動不頻繁，而且量不大，但是業務上基本沒有需要和快遞員join的場景，作為非分片表；
客戶表根據客戶id做哈希取模；
運單狀態信息表，運單狀態信息表記錄狀態的解釋信息，做為公共表。

運單根據量放在3個分片節點上，客戶根據量也放在兩個分片節點上。（這里假設都撐得住未來10年的量，主要要考慮存儲量級和tps/qps兩個維度，采用涉及到哈希取模的分片規則，最好一開始就估計足量，避免未來的擴容麻煩）

綜上，如下分片：

2. 配置conf/server.xml

server.xml幾乎保存了所有mycat需要的系統配置信息。其在代碼內直接的映射類為SystemConfig類。
參考完整配置：

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE mycat:server SYSTEM "server.dtd"> <mycat:server xmlns:mycat="http://org.opencloudb/"> <system> <property name="defaultSqlParser">druidparser</property> <!-- <property name="useCompression">1</property>--> <!--1為開啟mysql壓縮協議--> <!-- <property name="processorBufferChunk">40960</property> --> <!-- <property name="processors">1</property> <property name="processorExecutor">32</property> --> <!--默認是65535 64K 用於sql解析時最大文本長度 --> <!--<property name="maxStringLiteralLength">65535</property>--> <!--<property name="sequnceHandlerType">0</property>--> <!-- 表示使用數據庫方式生成sequence. --> <property name="sequnceHandlerType">1</property> <!--<property name="backSocketNoDelay">1</property>--> <!--<property name="frontSocketNoDelay">1</property>--> <!--<property name="processorExecutor">16</property>--> <!-- <property name="mutiNodeLimitType">1</property> 0：開啟小數量級（默認） ；1：開啟億級數據排序 <property name="mutiNodePatchSize">100</property> 億級數量排序批量 <property name="processors">32</property> <property name="processorExecutor">32</property> <property name="serverPort">8066</property> <property name="managerPort">9066</property> <property name="idleTimeout">300000</property> <property name="bindIp">0.0.0.0</property> <property name="frontWriteQueueSize">4096</property> <property name="processors">32</property> --> <property name="serverPort">8066</property> <property name="managerPort">9066</property> </system> <user name="root"> <!--從1.4.1開始，MyCat支持密文保存密碼,這里明文密碼為root --> <property name="usingDecrypt">1</property> <property name="password">CrjpLhvVJkHk0EPW35Y07dUeTimf52zMqClYQkIAN3/dqiG1DVUe9Zr4JLh8Kl+1KH1zd7YTKu5w04QgdyQeDw==</property> <property name="schemas">schema1</property> </user> <user name="test"> <!--這里明文密碼為test--> <property name="usingDecrypt">1</property>