通過上一篇的幾個優化方案，我們的索引速度其實已經能得到很大的提升了，從最初的平均每臺機器7000TPS/S，大概能到2.5WTPS/S。但是這個速度遠遠還達不到我們的需求，最關鍵的時候隨着節點數增加並不能速度並不能線性增加，然後又做了許多其他方面的嘗試，其中路由方式是比較大的一個方向，本篇將重點介紹這一方案。
前面介紹了solr在創建索引庫的時候可以指定多個shard來同時索引數據，那麼問題來了，文檔是通過何種規則講數據負載均衡到每個分片之上的呢，solr提供了兩種路由方式：哈希路由（composite）,指定路由（implict）。其中哈希路由，創建collection的時候需要明確指定shard數量，後期shard可以進行分裂（split）操作，但是不能增加或者刪除shard。solr默認的就是採用這種路由模式，利用計算文檔ID的哈希值，來判斷將此文檔索引到哪個分片之上，這樣做的好處是可以使得每個shard上數據負載均衡，但在追求極限速度之下，會浪費掉不少時間。第一，計算hash值需要耗時；第二，數據在各個分片之間遷徙分發需要消耗網絡以及內存資源。所以我們選擇了直接路由模式。工作模式如下圖，透過collection，直接指定分片載入數據：
直接路由模式顧名思義，指定索引具體落在路由到哪個shard，該模式同樣在創建collection時需要具體指定shard數量，後期可以動態追加分片以及刪除分片，但是如果一個分片過大時不能進行分裂的。需要注意的是：
1）索引要特殊方式通過以下URL新建
http://xxxx.xxxx.xxx.xxx:port/solr/admin/collections?action=CREATE&name=implicit1&shards=shard1,shard2,shard3&router.name=implicit2）在solr4.x版本中通過更改schemal.xml在5.0以上更改managed-schema文件添加以下字段定義：
<field name="_route_" type="string"/>3）利用SolrJ添加文檔的時候需要加入以下字段：
doc.addField("_route_","shard_x")通過直接路由的模式，我們可以每個線程操作一個shard，如果物理機上有多塊硬盤，就可以每個硬盤上部署一個solr節點，這樣多塊硬盤之間的索引性能是互不影響的，我們就可以隨着節點數的增加而線性增長。帶來的問題就是可能會導致數據分佈不均，而使某個分片過載，不過我們系統中數據中間件使用的是apache kafka，一個topic設置了多個partiton，在這一層報文已經做了一次均衡路由，每個partiton消費出來的數據負責寫一個solr的shard，所以不用擔心這個問題，後面有機會介紹下kafka消息中間件。
通過具體測試，指定路由速度相比於哈希路由，在單節點下速度並沒有提升，但是在多節點下，集羣的吞吐量有明顯的提升，可以真正做到水平拓展，對於物理機數量充足的情況下，可以滿足每天海量索引的更新。下一篇將繼續介紹如何利用solrj客戶端來提高單節點的速度，這樣整個集羣的吞吐量又能進一步提高。