jedisException问题排查client machine‘s system load may be tooHigh, check it‘s cpu load and gc status

问题：
使用redis的时候遇到报错：deps.redis.clients.jedis.exceptions.JedisException: client machine’s system load may be too high, please check it’s cpu load and gc status.

疑问：看到这个报错信息，有点懵。没有想到jedisException和客户端机器怎么会有联系？？？？

排查记录：通过trace查看，当前报错是执行string类型中mget命令的时候报错的，耗时大约有200ms左右,到这里初步定位是客户端机器调用redis的时候超时导致。另外一个问题来了，网络超时为啥会提示客户端机器load和gc可能有问题呢？

查看源码：


通过源码发现mget命令内部是通过线程池来实现，将多个元素查找的过程拆解成批量操作的任务到线程池中（批量操作里面会护法分出具体到每个集群节点的小任务），这个异常仅仅是在提交任务到线程池的时候发现了时间超过设置的超时时间100ms，所以可能是机器问题导致，比如一次gc停顿超过了100ms。
所以multiGet的原理是通过线程池批量创建任务，创建任务超时会报当前错误，client机器gc时间长会导致创建任务时间超时，且同一时间确实有 java.util.concurrent.RejectedExecutionException。很有可能是机器问题导致，如果是client机器问题导致，应该集中在某台机器上，排查确实都是某一台机器报错。

得出结论：yongGC时间过长导致当前错误。
请求超时是multiGet提交任务超时，而非网络超时，也非redis集群问题导致

使用mget的限制：通过以上排查确认了mget的使用场景比较苛刻，线上使用此命令应谨慎，对系统机器要求较高，容易出现超时问题

下面我们来对比下使用mget和多次进行get的区别：
mget的时间复杂度是o(n),其中n是请求元素的数量，get的时间复杂度是o(1)，从时间复杂度上看要请求n个数据没有区别
下面对比下网络io的区别：
执行一次mget请求的网络请求真的是1次吗？其实也不尽然
键值数据库或者缓存系统，由于通常采用hash函数将key映射到对应的实例，造成key的分布与业务无关，但是由于数据量、访问量的需求，需要使用分布式后（无论是客户端一致性哈性、redis-cluster、codis），批量操作比如批量获取多个key(例如redis的mget操作)，通常需要从不同实例获取key值，相比于单机批量操作只涉及到一次网络操作，分布式批量操作会涉及到多次网络io。

如果不考虑缓存架构，只拿单节点来说，mget的网络次数是1，n次get请求网络次数是n，mget请求更高效一些。因此，在执行请求命令的机器性能较好的情况下，mget效率比多次get请求效率要高些