ES緩存與redis緩存

① 緩存-redis 三種模式搭建和運行原理

標簽： redis 緩存 主從 哨兵 集群

本文簡單的介紹redis三種模式在linux的安裝部署和數據存儲的總結，希望可以相互交流相互提升。

對於Centos7在安裝redis之前需要進行一些常用工具的安裝：

關閉防火牆

正式安裝redis

在redis進行maketest時候會出現一系列的異常，有如下解決方案：

用redis-server啟動一下redis，做一些實驗沒什麼意義。

要把redis作為一個系統的daemon進程去運行的，每次系統啟動，redis進程一起啟動，操作不走如下：

RDB和AOF是redis的一種數據持久化的機制。 持久化 是為了避免系統在發生災難性的系統故障時導致的系統數據丟失。我們一般會將數據存放在本地磁碟，還會定期的將數據上傳到雲伺服器。
RDB 是redis的snapshotting，通過redis.conf中的save配置進行設置，如 save 60 1000:

AOF 是以appendonly方式進行數據的儲存的，開啟AOF模式後，所有存進redis內存的數據都會進入os cache中,然後默認1秒執行一次fsync寫入追加到appendonly.aof文件中。一般我們配置redis.conf中的一下指令：

AOF和RDB模式我們一般在生產環境都會打開，一般而言，redis服務掛掉後進行重啟會優先家在aof中的文件。

當啟動一個slave node的時候，它會發送一個PSYNC命令給master node,如果這是slave node重新連接master node，那麼master node僅僅會復制給slave部分缺少的數據;否則如果是slave node第一次連接master node，那麼會觸發一次full resynchronization;
開始full resynchronization的時候，master會啟動一個後台線程，開始生成一份RDB快照文件，同時還會將從客戶端收到的所有寫命令緩存在內存中。RDB文件生成完畢之後，master會將這個RDB發送給slave，slave會先寫入本地磁碟，然後再從本地磁碟載入到內存中。然後master會將內存中緩存的寫命令發送給slave，slave也會同步這些數據。
slave node如果跟master node有網路故障，斷開了連接，會自動重連。master如果發現有多個slave node都來重新連接，僅僅會啟動一個rdb save操作，用一份數據服務所有slave node。

從redis 2.8開始，就支持主從復制的斷點續傳，如果主從復制過程中，網路連接斷掉了，那麼可以接著上次復制的地方，繼續復制下去，而不是從頭開始復制一份。

master node會在內存中常見一個backlog，master和slave都會保存一個replica offset還有一個master id，offset就是保存在backlog中的。如果master和slave網路連接斷掉了，slave會讓master從上次的replica offset開始繼續復制,但是如果沒有找到對應的offset，那麼就會執行一次resynchronization。

master在內存中直接創建rdb，然後發送給slave，不會在自己本地落地磁碟了，可以有如下配置：

slave不會過期key，只會等待master過期key。如果master過期了一個key，或者通過LRU淘汰了一個key，那麼會模擬一條del命令發送給slave。

在redis.conf配置文件中，上面的參數代表至少需要3個slaves節點與master節點進行連接，並且master和每個slave的數據同步延遲不能超過10秒。一旦上面的設定沒有匹配上，則master不在提供相應的服務。

sdown達成的條件很簡單，如果一個哨兵ping一個master，超過了 is-master-down-after-milliseconds 指定的毫秒數之後，就主觀認為master宕機
sdown到odown轉換的條件很簡單，如果一個哨兵在指定時間內，收到了 quorum 指定數量的其他哨兵也認為那個master是sdown了，那麼就認為是odown了，客觀認為master宕機

如果一個slave跟master斷開連接已經超過了down-after-milliseconds的10倍，外加master宕機的時長，那麼slave就被認為不適合選舉為master

(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state

每次一個哨兵要做主備切換，首先需要quorum數量的哨兵認為odown，然後選舉出一個slave來做切換，這個slave還得得到majority哨兵的授權，才能正式執行切換；

（2）SENTINEL RESET *，在所有sentinal上執行，清理所有的master狀態
（3）SENTINEL MASTER mastername，在所有sentinal上執行，查看所有sentinal對數量是否達成了一致

4.3.2 slave的永久下線

讓master摘除某個已經下線的slave：SENTINEL RESET mastername，在所有的哨兵上面執行.

redis的集群模式為了解決系統的橫向擴展以及海量數據的存儲問題，如果你的數據量很大，那麼就可以用redis cluster。
redis cluster可以支撐N個redis master,一個master上面可以掛載多個slave，一般情況我門掛載一個到兩個slave，master在掛掉以後會主動切換到slave上面，或者當一個master上面的slave都掛掉後，集群會從其他master上面找到冗餘的slave掛載到這個master上面，達到了系統的高可用性。

2.1 redis cluster的重要配置

2.2 在三台機器上啟動6個redis實例

將上面的配置文件，在/etc/redis下放6個，分別為: 7001.conf，7002.conf，7003.conf，7004.conf，7005.conf，7006.conf

每個啟動腳本內，都修改對應的埠號

2.3 創建集群

解決辦法是 先安裝rvm，再把ruby版本提升至2.3.3

使用redis-trib.rb命令創建集群

--replicas: 表示每個master有幾個slave

redis-trib.rb check 192.168.31.187:7001 查看狀體

3.1 加入新master

以上相同配置完成後，設置啟動腳本進行啟動；然後用如下命令進行node節點添加：

3.2 reshard一些數據過去

3.3 添加node作為slave

3.4 刪除node

② java web開發緩存方案，ehcache和redis哪個更好

Ehcache在java項目廣泛的使用。它是一個開源的、設計於提高在數據從RDBMS中取出來的高花費、高延遲採取的一種緩存方案。正因為Ehcache具有健壯性（基於java開發）、被認證（具有apache2.0license）、充滿特色（稍後會詳細介紹），所以被用於大型復雜分布式webapplication的各個節點中。1.夠快Ehcache的發行有一段時長了，經過幾年的努力和不計其數的性能測試，Ehcache終被設計於large,highconcurrencysystems.2.夠簡單開發者提供的介面非常簡單明了，從Ehcache的搭建到運用運行僅僅需要的是你寶貴的幾分鍾。其實很多開發者都不知道自己用在用Ehcache，Ehcache被廣泛的運用於其他的開源項目比如：hibernate3.夠袖珍關於這點的特性，官方給了一個很可愛的名字smallfootprint，一般Ehcache的發布版本不會到2M，V2.2.3才668KB。4.夠輕量核心程序僅僅依賴slf4j這一個包，沒有之一！5.好擴展Ehcache提供了對大數據的內存和硬碟的存儲，最近版本允許多實例、保存對象高靈活性、提供LRU、LFU、FIFO淘汰演算法，基礎屬性支持熱配置、支持的插件多6.監聽器緩存管理器監聽器（CacheManagerListener）和緩存監聽器（CacheEvenListener）,做一些統計或數據一致性廣播挺好用的如何使用？夠簡單就是Ehcache的一大特色，自然用起來justsoeasy!redisredis是在memcache之後編寫的，大家經常把這兩者做比較，如果說它是個key-valuestore的話但是它具有豐富的數據類型，我想暫時把它叫做緩存數據流中心，就像現在物流中心那樣，order、package、store、classification、distribute、end。現在還很流行的LAMPPHP架構不知道和redis+mysql或者redis+mongodb的性能比較（聽群里的人說mongodb分片不穩定）。先說說reidis的特性1.支持持久化redis的本地持久化支持兩種方式：RDB和AOF。RDB在redis.conf配置文件里配置持久化觸發器，AOF指的是redis沒增加一條記錄都會保存到持久化文件中（保存的是這條記錄的生成命令），如果不是用redis做DB用的話還會不要開AOF，數據太龐大了，重啟恢復的時候是一個巨大的工程！2.豐富的數據類型redis支持String、Lists、sets、sortedsets、hashes多種數據類型,新浪微博會使用redis做nosql主要也是它具有這些類型，時間排序、職能排序、我的微博、發給我的這些功能List和sortedset的強大操作功能息息相關3.高性能這點跟memcache很想像，內存操作的級別是毫秒級的比硬碟操作秒級操作自然高效不少，較少了磁頭尋道、數據讀取、頁面交換這些高開銷的操作！這也是NOSQL冒出來的原因吧，應該是高性能是基於RDBMS的衍生產品，雖然RDBMS也具有緩存結構，但是始終在app層面不是我們想要的那麼操控的。4.replicationredis提供主從復制方案，跟mysql一樣增量復制而且復制的實現都很相似，這個復制跟AOF有點類似復制的是新增記錄命令，主庫新增記錄將新增腳本發送給從庫，從庫根據腳本生成記錄，這個過程非常快，就看網路了，一般主從都是在同一個區域網，所以可以說redis的主從近似及時同步，同事它還支持一主多從，動態添加從庫，從庫數量沒有限制。主從庫搭建，我覺得還是採用網狀模式，如果使用鏈式（master-slave-slave-slave-slave·····）如果第一個slave出現宕機重啟，首先從master接收數據恢復腳本，這個是阻塞的，如果主庫數據幾TB的情況恢復過程得花上一段時間，在這個過程中其他的slave就無法和主庫同步了。5.更新快這點好像從我接觸到redis到目前為止已經發了大版本就4個，小版本沒算過。redis作者是個非常積極的人，無論是郵件提問還是論壇發帖，他都能及時耐心的為你解答，維護度很高。有人維護的話，讓我們用的也省心和放心。目前作者對redis的主導開發方向是redis的集群方向。所以如果希望簡單就用ehcache，如果開發任務比較復雜，希望得到比較多的支持什麼的就redis

③ Redis應用場景

Redis實際應用場景
1、顯示最新的項目列表
下面這個語句常用來顯示最新項目，隨著數據多了，查詢毫無疑問會越來越慢。
SELECT FROM fOO WHERE ORDER BY time DESC LIMIT 10
在Web應用中，「列出最新的回復」之類的查詢非常普遍，這通常會帶來可擴展性問題。這令人沮喪，因為項目本來就是按這個順序被創建的，但要輸出這個順序卻不得不進行排序操作。類似的問題就可以用Redis來解決。比如說，我們的一個Web應用想要列出用戶貼出的最新20條評論。在最新的評論邊上我們有一個「顯示全部」的鏈接，點擊後就可以獲得更多的評論。我們假設資料庫中的每條評論都有一個唯一的遞增的ID欄位。我們可以使用分頁來製作主頁和評論頁，使用Redis的模板，每次新評論發表時，我們會將它的ID添加到一個Redis列表：
LPUSH latest.comments <ID>
我們將列表裁剪為指定長度，因此Redis只需要保存最新的5000條評論：
LTRIM latest.comments 0 5000
每次我們需要獲取最新評論的項目范圍時，我們調用一個函數來完成（使用偽代碼）：
FUNCTION get_latest_comments(start,num_items):
id list =redis.lrange("latest.comments",start,start+num items -1) IF id list.length<num items
id list = SQL DB("SELECT ... ORDER BY time LIMIT ...") END
RETURN id list END
這里我們做的很簡單。在Redis中我們的最新ID使用了常駐緩存，這是一直更新的。但是我們做了限制不能超過5000個ID，因此我們的獲取ID函數會一直詢問Redis。只有在start/count參數超出了這個范圍的時候，才需要去訪問資料庫。
我們的系統不會像傳統方式那樣「刷新」緩存，Redis實例中的信息永遠是一致的。SQL資料庫（或是硬碟上的其他類型資料庫）只是在用戶需要獲取「很遠」的數據時才會被觸發，而主頁或第一個評論頁是不會麻煩到硬碟上的資料庫了。

④ Redis在企業中都做什麼用，用大白話講，說明白了就行

Redis是由義大利人Salvatore Sanfilippo（網名：antirez）開發的一款內存高速緩存資料庫。Redis全稱為：Remote Dictionary Server（遠程數據服務），該軟體使用C語言編寫，Redis是一個key-value存儲系統，它支持豐富的數據類型，如：string、list、set、zset(sorted set)、hash。眾多語言都支持Redis，因為Redis交換數據快，所以在伺服器中常用來存儲一些需要頻繁調取的數據，這樣可以大大節省系統直接讀取磁碟來獲得數據的I/O開銷，更重要的是可以極大提升速度
拿大型網站來舉個例子，比如a網站首頁一天有100萬人訪問，其中有一個板塊為推薦新聞。要是直接從資料庫查詢，那麼一天就要多消耗100萬次資料庫請求。上面已經說過，Redis支持豐富的數據類型，所以這完全可以用Redis來完成，將這種熱點數據存到Redis（內存）中，要用的時候，直接從內存取，極大的提高了速度和節約了伺服器的開銷。

⑤ Redis簡介以及和其他緩存資料庫的區別

Redis 是一個開源的內存中的數據結構存儲系統，它可以用作資料庫、緩存和消息中間件。
它支持多種類型的數據結構，如字元串（Strings），散列（Hashes），列表（Lists），集合（Sets），有序集合（Sorted Sets或者是ZSet） 與范圍查詢， Bitmaps，Hyperloglogs 和 地理空間（Geospatial）索引半徑查詢。 其中常見的數據結構類型有String、List、Set、Hash、ZSet這5種。

⑥ Redis 可以用來做資料庫嗎

redis能否做資料庫用取決於如下幾個條件：
1：數據量，畢竟內存資料庫，還是受限於內存的容量，雖然可以redis可以持久化。
2：數據的結構，是否能夠將關系型數據結構都轉換為key/value的形式。
3：查詢的效率，對范圍查詢等，是否能轉換為高效的hash索引查詢

redis能不能拿來當資料庫，取決於你想要存儲什麼數據：
如果你打算存儲一些臨時數據，數據規模不大，不需要太復雜的查詢，但是對性能的要求比較高，那可以拿redis當資料庫使用。
否則別拿來當資料庫用。

redis 能不能做資料庫，要看你具體的需求了：
1. 像上面提到的，redis的持久化有問題，如果使用aof模式，並且fsync always，則性能比mysql 還低，如果你喜歡redis 方便的數據結構而對性能要求不高，或者性能要求很高，但允許一定程度的丟失數據，則可以用redis做為資料庫。
2. redis 是內存資料庫， 內存寫滿後，數據不會存儲到硬碟上（VM 不穩定，diskstore未啟用），如果你內存足夠大，則可以用redis作為資料庫。

redis是一種k/v的內存資料庫，適合小數據量的存儲以及實時要求高的地方，但是不適合做完整資料庫，完整資料庫基本上都有一套詳細解決方案，基本上沒有做了的，比如mysql。

項目里用到的redis是用來做緩存的，設置過期時間，到時就自動清掉。資料庫還是用mysql等這種成熟的方案。
如果你非要用一種nosql來做資料庫，推薦你用Mongodb。

這種KV存儲完全不具備資料庫所能提供的數據安全性保障。
所以還是用來做緩存比較合適。

redis做資料庫不靠譜，不是所有的數據都是立即回寫磁碟的。

⑦ java web開發緩存方案，ehcache和redis哪個更好

java web開發緩存方案，ehcache和redis各有優劣勢，對比如下：

1、適合使用ehcache的場景：

選用Ehcache作為數據存儲伺服器，Ehcache也是基於內存存儲，支持定時持久化功能，非常適合存儲像計數器這種小數據類型。處理Http請求使用Tomcat容器，結構圖如下：

實現原理：處理邏輯採用一個servlet實現，並且在這個servlet中通過一致性Hash從Ehcache中獲取計數器值。

2、高並發並且對實時性要求高的場合下使用redis

redis

redis是在memcache之後編寫的，大家經常把這兩者做比較，如果說它是個key-value store 的話但是它具有豐富的數據類型，我想暫時把它叫做緩存數據流中心，就像現在物流中心那樣，order、package、store、classification、distribute、end。現在還很流行的LAMP PHP架構 不知道和redis+mysql 或者redis+ mongodb的性能比較（聽群里的人說mongodb分片不穩定）。

先說說reidis的特性

1. 支持持久化

redis的本地持久化支持兩種方式：RDB和AOF。RDB 在redis.conf配置文件里配置持久化觸發器，AOF指的是redis沒增加一條記錄都會保存到持久化文件中（保存的是這條記錄的生成命令），如果不是用redis做DB用的話還會不要開AOF ，數據太龐大了，重啟恢復的時候非常麻煩。

2.豐富的數據類型

redis支持 String 、Lists、sets、sorted sets、hashes 多種數據類型,新浪微博會使用redis做nosql主要也是它具有這些類型，時間排序、職能排序、我的微博、發給我的這些功能List和sorted set 的強大操作功能息息相關。

3.高性能

這點跟memcache很想像，內存操作的級別是毫秒級的比硬碟操作秒級操作自然高效不少，較少了磁頭尋道、數據讀取、頁面交換這些高開銷的操作！這也是NOSQL冒出來的原因吧，應該是高性能

是基於RDBMS的衍生產品，雖然RDBMS也具有緩存結構，但是始終在app層面不是我們想要的那麼操控的。

4.replication

redis提供主從復制方案，跟mysql一樣增量復制而且復制的實現都很相似，這個復制跟AOF有點類似復制的是新增記錄命令，主庫新增記錄將新增腳本發送給從庫，從庫根據腳本生成記錄，這個過程非常快，就看網路了，一般主從都是在同一個區域網，所以可以說redis的主從近似及時同步，同事它還支持一主多從，動態添加從庫，從庫數量沒有限制。 主從庫搭建，我覺得還是採用網狀模式，如果使用鏈式（master-slave-slave-slave-slave·····）如果第一個slave出現宕機重啟，首先從master 接收 數據恢復腳本，這個是阻塞的，如果主庫數據幾TB的情況恢復過程得花上一段時間，在這個過程中其他的slave就無法和主庫同步了。

5.更新快

這點好像從我接觸到redis到目前為止 已經發了大版本就4個，小版本沒算過。redis作者是個非常積極的人，無論是郵件提問還是論壇發帖，他都能及時耐心的為你解答，維護度很高。有人維護的話，讓我們用的也省心和放心。目前作者對redis的主導開發方向是redis的集群方向。

⑧ Redis和Memcache的區別分析

總結一：
memcache官方定義
Free & open source, high-performance, distributed memory object caching system, generic in nature, but intended for use in speeding up dynamic web applications by alleviating database load.
redis官方定義
Redis is an open source, BSD licensed, advanced key-value store. It is often referred to as a data structure server since keys can contain strings, hashes, lists, sets and sorted sets.
版權相同
它們都是使用的bsd協議，使用它的項目可以用於商業用戶，不必發布二次修改的代碼，可以修改源代碼。
數據類型
redis數據類型豐富，支持set liset等類型
memcache支持簡單數據類型，需要客戶端自己處理復雜對象
持久性
redis支持數據落地持久化存儲
memcache不支持數據持久存儲
分布式存儲
redis支持master-slave復制模式
memcache可以使用一致性hash做分布式
value大小不同
memcache是一個內存緩存，key的長度小於250字元，單個item存儲要小於1M，不適合虛擬機使用
數據一致性不同
redis使用的是單線程模型，保證了數據按順序提交。
memcache需要使用cas保證數據一致性。CAS（Check and Set）是一個確保並發一致性的機制，屬於「樂觀鎖」范疇；原理很簡單：拿版本號，操作，對比版本號，如果一致就操作，不一致就放棄任何操作
cpu利用
redis單線程模型只能使用一個cpu，可以開啟多個redis進程
總結二：
1.Redis中，並不是所有的數據都一直存儲在內存中的，這是和Memcached相比一個最大的區別。
2.Redis不僅僅支持簡單的k/v類型的數據，同時還提供list，set，hash等數據結構的存儲。
3.Redis支持數據的備份，即master-slave模式的數據備份。
4.Redis支持數據的持久化，可以將內存中的數據保持在磁碟中，重啟的時候可以再次載入進行使用。
我個人認為最本質的不同是Redis在很多方面具備資料庫的特徵，或者說就是一個資料庫系統，而Memcached只是簡單的K/V緩存
總結三：
redis和memecache的不同在於：
1、存儲方式：
memecache 把數據全部存在內存之中，斷電後會掛掉，數據不能超過內存大小
redis有部份存在硬碟上，這樣能保證數據的持久性。
2、數據支持類型：
redis在數據支持上要比memecache多的多。
3、使用底層模型不同：
新版本的redis直接自己構建了VM 機制 ，因為一般的系統調用系統函數的話，會浪費一定的時間去移動和請求。
4、運行環境不同：
redis目前官方只支持LINUX 上去行，從而省去了對於其它系統的支持，這樣的話可以更好的把精力用於本系統 環境上的優化，雖然後來微軟有一個小組為其寫了補丁。但是沒有放到主幹上
memcache只能當做緩存，cache
redis的內容是可以落地的，就是說跟mongodb有些類似，然後redis也可以作為緩存，並且可以設置master-slave

⑨ es與redis哪個查詢快

es建立索引相對來說比較快,對於大數據量的實時查詢非常有幫助。

⑩ ES大數據量下的查詢優化

filesystem類似於我們在mysql上建立一層redis緩存；

es的搜索引擎嚴重依賴於底層的filesystem cache，如果給filesystem cache更多的內存，盡量讓內存可以容納所有的indx segment file索引數據文件，那麼你搜索的時候就基本都是走內存的，性能會非常高。

兩者差距非常大，走磁碟和走systenfile cache的讀取的性能差距可以說是秒級和毫秒級的差距了；

要讓es性能要好，最佳的情況下，就是我們的機器的內存，至少可以容納你的數據量的一半

最佳的情況下，是僅僅在es中就存少量的數據，存儲要用來搜索的那些索引，內存留給filesystem cache的，如果就100G，那麼你就控制數據量在100gb以內，相當於是，你的數據幾乎全部走內存來搜索，性能非常之高，一般可以在1秒以內

的少數幾個欄位就可以了，比如說，就寫入es id name age三個欄位就可以了，然後你可以把其他的欄位數據存在mysql裡面，我們一般是建議用 es + hbase 的一個架構。
hbase的特點是適用於海量數據的在線存儲，就是對hbase可以寫入海量數據，不要做復雜的搜索，就是做很簡單的一些根據id或者范圍進行查詢的這么一個操作就可以了

如果確實內存不足，但是我們又存儲了比較多的數據，比如只有30g給systemfile cache，但是存儲了60g數據情況，這種情況可以做數據預熱；

我們可以將一些高頻訪問的熱點數據（比如微博知乎的熱榜榜單數據，電商的熱門商品（旗艦版手機，榜單商品信息）等等）提前預熱，定期訪問刷到我們es里；（比如定期訪問一下當季蘋果旗艦手機關鍵詞，比如現在的iphone12）

對於那些你覺得比較熱的，經常會有人訪問的數據，最好做一個專門的緩存預熱子系統，就是對熱數據，每隔一段時間，提前訪問一下，讓數據進入filesystem cache裡面去。這樣下次別人訪問的時候，一定性能會好一些。

我們可以將冷數據寫入一個索引中，然後熱數據寫入另外一個索引中，這樣可以確保熱數據在被預熱之後，盡量都讓他們留在filesystem os cache里，別讓冷數據給沖刷掉。

盡量做到設計document的時候就把需要數據結構都做好，這樣搜索的數據寫入的時候就完成。對於一些太復雜的操作，比如join，nested，parent-child搜索都要盡量避免，性能都很差的。

es的分頁是較坑的 ，為啥呢？舉個例子吧，假如你每頁是10條數據，你現在要查詢第100頁，實際上是會把 每個shard上存儲的前1000條數據都查到 一個協調節點上，如果你有個5個shard，那麼就有5000條數據，接著 協調節點對這5000條數據進行一些合並、處理，再獲取到最終第100頁的10條數據。

因為他是分布式的，你要查第100頁的10條數據，你是不可能說從5個shard，每個shard就查2條數據？最後到協調節點合並成10條數據？這樣肯定不行，因為我們從單個結點上拿的數據幾乎不可能正好是所需的數據。我們必須得從每個shard都查1000條數據過來，然後根據你的需求進行排序、篩選等等操作，最後再次分頁，拿到裡面第100頁的數據。

你翻頁的時候，翻的越深，每個shard返回的數據就越多，而且協調節點處理的時間越長。非常坑爹。所以用es做分頁的時候，你會發現越翻到後面，就越是慢。

我們之前也是遇到過這個問題，用es作分頁，前幾頁就幾十毫秒，翻到10頁之後，幾十頁的時候，基本上就要5~10秒才能查出來一頁數據了

你系統不允許他翻那麼深的頁，或者產品同意翻的越深，性能就越差

如果是類似於微博中，下拉刷微博，刷出來一頁一頁的，可以用scroll api
scroll api1 scroll api2
scroll會一次性給你生成所有數據的一個快照，然後每次翻頁就是通過游標移動 ，獲取下一頁下一頁這樣子，性能會比上面說的那種分頁性能也高很多很多

scroll的原理實際上是保留一個數據快照，然後在一定時間內，你如果不斷的滑動往後翻頁的時候，類似於你現在在瀏覽微博，不斷往下刷新翻頁。那麼就用scroll不斷通過游標獲取下一頁數據，這個性能是很高的，比es實際翻頁要好的多的多。

缺點：