今天調試代碼的時候發現也很奇怪的問題：
如果把offset，改為小於4的數，就報如題錯誤，其他的請求都是正常；測試其他接口改為0也是正常。百度如題的原因，大部分都是這篇文章描述的問題：https://blog.csdn.net/china_bobo/article/details/53897989 但是我的檢查了不是這個，從上面的操作也不是這個問題。
后面又繼續看了錯誤的打印：
有這樣一些日志： Waiting server-side response timeout. start time: 2018-07-26 15:00:09.705, end time: 2018-07-26 15:00:10.707, client elapsed: 1 ms, server elapsed:
此時百度，說是請求超時，一開始也往這邊想了，但是只是請求十條數據，並且之前都是好了，就突然報錯。。。也只能死馬當活馬醫，就試試。。。改了服務端的響應時間，發現就好了。
附修改的代碼，給提供服務的服務配置超時時間
這是xml的dubbo配置
<dubbo:service interface="com.XXXX.XXXXX.IlampService" ref="lampService" timeout="1200000"/>注解的操作
@Service(
interfaceName = "cn.xlink.cecep.api.service.ILampService",
timeout = 1200000)目前解決方法就是這樣。
深層次的原因后面自己再去分析，應該 是以下原因一直：1、數據庫數據量大，未建立有效的索引，mongo里面的filter太多，查詢耗時，導致服務端響應慢，客戶端以為請求未響應，才報錯。2、網絡原因，因為mongodb和zk，在不同不服務，我這里是本地測試。 目前就能想到這兩個原因，后面有時間再研究。