起源
之前爬取過一百萬的歌曲，包括歌手名，歌詞等，最近瞭解到倒排索引，像es，solr這種太大，配置要求太高，對於一百萬的數據量有些小題大做，所以想到了redis做一個倒排索引。
我的配置
這裏說一下我的配置，後面用的到：
cpu：i7 8750HQ （六核十二線程）
內存：8G ddr4
硬盤：ssd（.m2接口）
思路
簡單來說就是把MySQL中的數據取出來，分詞（包括去除停用詞），將分詞後得到的一個個詞語存入redis。在redis當中，一個詞語就是一個set，set裏存放的是歌詞中包含這個詞語的歌的主鍵。
當我們生成這麼一個倒排索引後，就可以實現“搜索一句話，很快得到有這些話的歌曲集合”。
因爲一百萬的數據還是挺大的，所以考慮多線程執行，按過程來說分爲兩部分：
1、從數據庫中取出來，放到Redis的list結構裏去，使用list的lpush和rpop達到一種消息隊列的效果。
2、從Redis中rpop出一首歌，分詞，然後將分詞結果存入Redis，形成倒排索引。
下面就根據這兩部分講一下具體的實現。
實現
MySQL->Redis部分的實現
這一部分思路就是從MySQL中取出數據，使用FastJson進行序列化，存入key爲“dbWorkersKey”的list裏，這裏使用的是lpush命令。
我們把上面的思路封裝到一個Thread裏，多線程的去搬運就很快了。
多線程下有以下幾個問題和回答：
Q：我們使用的數據訪問工具是Spring的JdbcTemplate，他是線程安全的嗎
A：是線程安全的，Spring把session，connection這些非線程安全的使用ThreadLocal做了線程私有化，避免了這些問題。
Q：每個線程負責一塊數據，數據劃分怎麼做
A：使用了一個AtomicInteger，多個線程同時持有一個該對象，每次都incrementAndGet，在SQL語句中結合limit使用，做到數據的劃分。
Q：考慮到多線程，那肯定要用線程池了，線程池有什麼需要注意的嗎
A：有，因爲一個任務的很大的兩塊時間——從MySQL獲取數據和向Redis添加數據——都是網絡IO，爲了更好地利用處理器，我們可以把線程池大小設置爲2*核心數，同時別忘記把數據庫連接池的最大連接數設置爲大於線程數，比如我用的dbcp2默認的maxTotal是8。
Q：如何搬運完畢後自動停止
A：這裏因爲我知道搬運條目的總數量爲1106599，而且我每次獲取1000條，所以當AtomicInteger >1107時，就是結束的時候了
worker代碼如下：
static class DbWorker extends Thread {
private JdbcTemplate jdbcTemplate;
private RedisCacheManager redisCacheManager;
private String name;
private AtomicInteger atomicInteger;
public DbWorker(JdbcTemplate jdbcTemplate, RedisCacheManager redisCacheManager, String name, AtomicInteger atomicInteger) {
this.jdbcTemplate = jdbcTemplate;
this.redisCacheManager = redisCacheManager;
this.name = name;
setName(name);
this.atomicInteger = atomicInteger;
}
@Override
public void run() {
super.run();
long lastSongId = 0;
while (true) {
int index = atomicInteger.incrementAndGet();
if (index > 1107) {
System.out.println(TimeUtils.dateToString() + " dbWorkers-" + getName() + "-db中應該是沒有數據了，結束線程運行...-get index = " + index + " ... lastSongId = " + lastSongId);
return;
}
int start = (index - 1) * 1000;
List<Song> result = jdbcTemplate.query("select id,lyric from song limit " + start + ",1000", new Object[] {},
new BeanPropertyRowMapper<Song>(Song.class));
for (Song temp :
result) {
redisCacheManager.lpush(REDIS_DB_WORKERS_KEY, JSON.toJSONString(temp));
}
lastSongId = result.get(result.size()-1).getId();
System.out.println("dbWorkers-" + getName() + "-獲得" + result.size() + "條數據後已經將這些數據運往redis保存了，繼續下一次db獲取... -get index = " + index + " ... lastSongId = " + lastSongId);
}
}
}
消耗時間
當時設置的是16條線程，忘記修改最大連接數，導致最大連接數爲8，而且打印的內容有點多，所以，1106599條數據，從MySQL搬運到Redis用了7min16s的時間。
Redis->分詞->Redis中
這一部分主要是從Redis中使用rpop出一首歌，使用FastJson反序列化後，對歌詞進行分詞，這裏分詞使用的是結巴分詞的Java版本，將分詞結果去除停用詞後，存入key爲“song:詞語”的set結構中。
當然也要用到多線程了，要不得到啥時候去。
Q&A
Q：在多線程池中，注意的問題？
A：因爲分詞是一個計算型的任務，所以我們需要壓榨處理器，設置線程數爲核數+1，減少線程切換次數
Q：如果全部數據處理完畢，如何停止任務呢？
A：每次rpop出的value，如果爲空，則rpopIsNull計數器+1，併線程沉睡rpopIsNull*500毫秒，rpopIsNull大於5之後，退出線程。如果又一次rpop出的value不爲空，則將rpopIsNull重置爲0，這樣還可以避免生產者消費者的處理能力不均的問題。
其他：
A：注意多線程異常
A：停用詞使用的是結巴提供的詞語庫
A：使用SpringRedis的時候，他默認的序列化器是Java默認的序列化器，這個序列化器會在序列化後的內容最前頭加上類信息，每個key、value都有，看着不舒服的同時還浪費內存空間，我就換成了StringRedisSerializer，參考的這一篇文章，文章末還推薦了一片【Redis 內存優化】節約內存：Instagram的Redis實踐也很棒
A：使用VisualVM進行監控，特別是VisualVM中各個狀態的意義，還有如何分析出死鎖
A：Redis在生產環境中，使用keys，一般肯定把服務器打掛，一般使用scan和dbsize，具體文章點擊Redis查詢當前庫有多少個 key和2.1.1 列出key——極客學院課程
代碼：
static class FenCiWorker extends Thread {
private RedisCacheManager redisCacheManager;
private String name;
private int cantPop = 0;
private JiebaSegmenter segmenter;
public FenCiWorker(RedisCacheManager redisCacheManager,String name) {
this.redisCacheManager = redisCacheManager;
this.name = name;
setName(name);
segmenter = new JiebaSegmenter();
}
@Override
public void run() {
super.run();
long lastSongId = 0;
while (true) {
Object value = redisCacheManager.rpop(REDIS_DB_WORKERS_KEY);
if (value != null) {
cantPop = 0;
Song song = JSON.parseObject((String) value, Song.class);
lastSongId = song.getId();
String lyric = song.getLyric();
if (StringUtils.isEmpty(lyric)) {
// 多線程的異常，這裏如果不檢測lyric是否爲null，線程會報異常後不提示而結束...
continue;
}
// System.out.println(TimeUtils.dateToString() + " fenciWorker-" + getName() + "-開始處理一首歌 id = " + lastSongId);
List<SegToken> result = segmenter.process(lyric, JiebaSegmenter.SegMode.INDEX);
for (SegToken temp :
result) {
String word = temp.word;
if (!stopWordSet.contains(word)) {
redisCacheManager.sSet(REDIS_SONG_INDEX_PRE + word,song.getId().toString());
}
}
// System.out.println(TimeUtils.dateToString() + " fenciWorker-" + getName() + "-處理了完一首歌 id = " + lastSongId);
} else {
cantPop++;
if (cantPop >= 5) {
System.out.println(TimeUtils.dateToString() + " fenciWorker-" + getName() + "-超過5次沒有pop到數據，線程退出了... lastSongId = " + lastSongId);
return;
} else {
long sleep = cantPop * 500;
System.out.println(TimeUtils.dateToString() + " fenciWorker-" + getName() + "-已經+ " + cantPop + "次沒有pop到數據... 線程將沉睡" + sleep + " lastSongId = " + lastSongId);
try {
Thread.sleep(sleep);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
}
}
消耗時間
開了8個線程，花了16min35s，共1106559條數據，速度1112.12首/s。
到這裏，倒排索引就建好了，備份一下dump.rdb文件。
使用
簡單的實現思路，用戶輸入一句話，對這句話分詞，根據分詞結果去redis查詢，將查詢結果放到idSet裏，最後對idSet進行遍歷，使用主鍵去數據庫查詢。
不足
- 當直接查詢歌名時，但也做了分詞，查到很多沒用的記錄
- 查詢結果沒有根據與目標符合程度的排序
- 有的比如“我”，“愛”，“你”這種詞太多歌裏都有了，所以用這種詞查詢意義不大
優化
-
索引應該加入歌名，直接搜歌名
-
加入優先級屬性，比如搜歌名得到的結果應該放到最前面
-
其他的可以去查閱一些關於搜索的文章