redis 性能分享
站长
· 阅读数 18
Redis为什么变慢了? 带你如何排查redis性能问题
1. redis 真的变慢了吗？
在开始之前，首先要弄清楚 redis 是否真的变慢了？
如果你发现你的业务服务 API 响应延迟变长，首先你需要先排查服务内部，究竟是哪个环节拖慢了整个服务。比较高效的做法是，服务内部集成链路追踪，也就是在服务访问外部依赖的出入口，记录下每次请求外部依赖的响应延时。
当你真的定位到是操作redis这条链路耗时比较长，那么此刻你需要把焦点关注在业务服务到 Redis 这条链路上。
操作redis耗时较长，通常有两种原因：
- 网络原因：例如网络线路质量不佳，网络数据包在传输时存在延迟、丢包等情况
- redis自身原因
本文重点关注第二点
既然确认了是redis操作耗时，那么有哪些操作会导致redis变慢？首先需要对 redis 进行基准测试，充分了解 redis 在生成环境上的基准性能。
什么是基准性能？
简单来说，基准性能就是指 redis 在一台负载正常的机器上，最大响应延迟和平均响应延迟。
为什么要了解 redis 的基准性能?
因为只有了解了redis 服务器的基准性能，才能进一步评估，当其延迟达到什么程度时，才能判定 redis 是否真的变慢了。
如何查询redis的基准性能?
为了能真实查询出redis服务器的响应延迟情况，直接在 redis 服务器实例中执行以下命令：
$ redis-cli -h 127.0.0.1 -p 6379 --intrinsic-latency 60
Max latency so far: 1 microseconds.
Max latency so far: 15 microseconds.
Max latency so far: 17 microseconds.
Max latency so far: 18 microseconds.
Max latency so far: 31 microseconds.
Max latency so far: 32 microseconds.
Max latency so far: 59 microseconds.
Max latency so far: 72 microseconds.
1428669267 total runs (avg latency: 0.0420 microseconds / 42.00 nanoseconds per run).
Worst run took 1429x longer than the average latency.
从上述可以得出，60秒内最大的延迟是72微妙（0.072毫秒）。
通过以下命令可以查询 redis 服务器的最小、最大、平均访问延迟：
$ redis-cli -h 127.0.0.1 -p 6379 --latency-history -i 1
min: 0, max: 1, avg: 0.13 (100 samples) -- 1.01 seconds range
min: 0, max: 1, avg: 0.12 (99 samples) -- 1.01 seconds range
min: 0, max: 1, avg: 0.13 (99 samples) -- 1.01 seconds range
min: 0, max: 1, avg: 0.10 (99 samples) -- 1.01 seconds range
min: 0, max: 1, avg: 0.13 (98 samples) -- 1.00 seconds range
min: 0, max: 1, avg: 0.08 (99 samples) -- 1.01 seconds range
...
以上输出结果是，每间隔 1 秒，采样 Redis 的平均操作耗时，其结果分布在 0.08 ~ 0.13 毫秒之间。
了解了基准性能测试方法，那么你就可以按照以下几步，来判断你的 Redis 是否真的变慢了：
- 在相同配置的服务器上，测试一个正常 Redis 实例的基准性能
- 找到你认为可能变慢的 Redis 实例，测试这个实例的基准性能
- 如果你观察到，这个实例的运行延迟是正常 Redis 基准性能的 2 倍以上，即可认为这个 Redis 实例确实变慢了
那如果确认了 redis 变慢，我们应该从哪些方面去排查呢？
首先，Redis 提供跟Mysql一样的慢日志统计功能，用来记录耗时较长的命令信息。
查看 Redis 慢日志之前，你需要设置慢日志的阈值。例如，设置慢日志的阈值为 5 毫秒，并且保留最近 500 条慢日志记录：
# 命令执行耗时超过 5 毫秒，记录慢日志
CONFIG SET slowlog-log-slower-than 5000
# 只保留最近 500 条慢日志
CONFIG SET slowlog-max-len 500
设置完成之后，所有执行的命令如果操作耗时超过了 5 毫秒，都会被 Redis 记录下来。
此时，你可以执行以下命令，就可以查询到最近记录的慢日志：
127.0.0.1:6379> SLOWLOG get 5
1) 1) (integer) 32693 # 慢日志ID
2) (integer) 1593763337 # 执行时间戳
3) (integer) 5299 # 执行耗时(微秒)
4) 1) "LRANGE" # 具体执行的命令和参数
2) "user_list:2000"
3) "0"
4) "-1"
2) 1) (integer) 32692
2) (integer) 1593763337
3) (integer) 5044
4) 1) "GET"
2) "user_info:1000"
...
通过查看慢日志，我们就可以知道在什么时间点，执行了哪些命令比较耗时。
2. 使用复杂度过高的命令
* * *
如果操作 redis 命令具有以下特点，那么操作时可能会导致延迟过大：
0. 经常使用O(N)复杂度以上的命令，例如：SORT、SUNION、ZUNIONSTORE 聚合类命令
0. 使用 O(N) 复杂度的命令，但 N 的值非常大
时间复杂度过高，在操作redis内存时，CPU会消耗大量的时间；redis一次性返回客户端的数据太大，在数据协议的组装和网络传输过程中花费大量的时间。
需要强调的是，Redis是单线程处理客户端请求，如果你经常使用上述命令，在redis服务器在处理请求时，如果正好处理的是复杂度过高的命令，cpu处理时间过长，会导致其他命令等待的时间过长。
那如何处理这种情况呢？
0. 尽量不使用 O(N) 以上复杂度过高的命令，对于数据的聚合操作，放在客户端做
0. 执行 O(N) 命令，保证 N 尽量的小（推荐 N <= 300），每次获取尽量少的数据，让 Redis 可以及时处理返回
3. 操作 bigKey
* * *
如果通过日志查询，发现并非是复杂度很高的命令导致，而是SET/DEL这种简单命令出现在日志中，此时你需要怀疑是不是在操作bigKey导致的。
如果一个key对应的value非常大，那么redis在分配内存/释放内存是非常耗时的。所以在操作时，业务方需要评估写入一个key的数据大小，避免存入一个key过大的数据。
在redis中，可以通过命令扫码实例中bigkey的分布情况，如下：
```
$ redis-cli -h 127.0.0.1 -p 6379 --bigkeys -i 0.01
...
-------- summary -------
Sampled 829675 keys in the keyspace!
Total key length in bytes is 10059825 (avg len 12.13)
Biggest string found 'key:291880' has 10 bytes
Biggest list found 'mylist:004' has 40 items
Biggest set found 'myset:2386' has 38 members
Biggest hash found 'myhash:3574' has 37 fields
Biggest zset found 'myzset:2704' has 42 members
36313 strings with 363130 bytes (04.38% of keys, avg size 10.00)
787393 lists with 896540 items (94.90% of keys, avg size 1.14)
1994 sets with 40052 members (00.24% of keys, avg size 20.09)
1990 hashs with 39632 fields (00.24% of keys, avg size 19.92)
1985 zsets with 39750 members (00.24% of keys, avg size 20.03)
```
从输出结果我们可以很清晰地看到，每种数据类型所占用的最大内存 / 拥有最多元素的 key 是哪一个，以及每 种数据类型在整个实例中的占比和平均大小 / 元素数量。
这里我需要提醒你的是，当执行这个命令时，要注意 2 个问题：
0. 对线上实例进行 bigkey 扫描时，Redis 的 OPS 会突增，为了降低扫描过程中对 Redis 的影响，最好控制一下扫描的频率，指定 -i 参数即可，它表示扫描过程中每次扫描后休息的时间间隔，单位是秒
0. 扫描结果中，对于容器类型（List、Hash、Set、ZSet）的 key，只能扫描出元素最多的 key。但一个 key 的元素多，不一定表示占用内存也多，你还需要根据业务情况，进一步评估内存占用情况
对于bigkey导致延迟的问题，有以下集中解决方案:
0. 业务方尽量避免写入bigkey（**推荐**）
0. 如果你使用的 Redis 是 4.0 以上版本，用 UNLINK 命令替代 DEL，此命令可以把释放 key 内存的操作，放到后台线程中去执行，从而降低对 Redis 的影响
0. 如果你使用的 Redis 是 6.0 以上版本，可以开启 lazy-free 机制（lazyfree-lazy-user-del = yes），在执行 DEL 命令时，释放内存也会放到后台线程中执行
4. 集中过期
* * *
如果你发现，平时在操作 Redis 时，并没有延迟很大的情况发生，但在某个时间点突然出现一波延时，其现象表现为：**变慢的时间点很有规律，例如某个整点，或者每间隔多久就会发生一波延迟。**
如果出现上述情况，那就需要排查下，业务代码中是否设置了大量key在集中过期的情况。因为在大量key集中过期也会导致reids延迟扩大。
在介绍具体原因之前，先来了解下redis针对过期key的淘汰策略。redis默认采用两种过期策略:
0. 惰性策略：在查询key的时候，先检查key是否过期，如果过期，则从实例中删除。
0. 定期策略：依赖redis定时任务，默认每隔 100 毫秒（1秒10次）就会从全局的过期哈希表中随机取出 20 个 key，然后删除其中过期的 key，如果过期 key 的比例超过了 25%，则继续重复此过程，直到过期 key 的比例下降到 25% 以下，或者这次任务的执行耗时超过了 25 毫秒，才会退出循环
注意，**这个主动过期 key 的定时任务，是在 Redis 主线程中执行的**。
也就是说如果在执行主动过期的过程中，出现了需要大量删除过期 key 的情况，那么此时应用程序在访问 Redis 时，必须要等待这个过期任务执行结束，Redis 才可以服务这个客户端请求。
如果此时需要过期删除的是一个 bigkey，那么这个耗时会更久。而且，**这个操作延迟的命令并不会记录在慢日志中**。
因为慢日志中**只记录一个命令真正操作内存数据的耗时**，而 Redis 主动删除过期 key 的逻辑，是在命令真正执行之前执行的。
那么遇到这种情况，如何处理好喝规避？
0. 集中过期 key 增加一个随机过期时间，把集中过期的时间打散，降低 Redis 清理过期 key 的压力
0. 如果你使用的 Redis 是 4.0 以上版本，可以开启 lazy-free 机制，当删除过期 key 时，把释放内存的操作放到后台线程中执行，避免阻塞主线程
5. 实例内存达到上限
* * *
redis 实例的内存都会设置一个最大值，当内存使用到达最大值时，会通过设置的淘汰策略进行回收。
当 redis 实例的内存使用到达上限时，会发现，之后写入新的数据，都会变得很慢。那是因为在新的数据写入之前，都会将老的数据进行回收，这样才能将新的数据写入。
这个踢出旧数据的逻辑也是需要消耗时间的，而具体耗时的长短，要取决于你配置的淘汰策略：
- allkeys-lru：不管 key 是否设置了过期，淘汰最近最少访问的 key
- volatile-lru：只淘汰最近最少访问、并设置了过期时间的 key
- allkeys-random：不管 key 是否设置了过期，随机淘汰 key
- volatile-random：只随机淘汰设置了过期时间的 key
- allkeys-ttl：不管 key 是否设置了过期，淘汰即将过期的 key
- noeviction：不淘汰任何 key，实例内存达到 maxmeory 后，再写入新数据直接返回错误
- allkeys-lfu：不管 key 是否设置了过期，淘汰访问频率最低的 key（4.0+版本支持）
- volatile-lfu：只淘汰访问频率最低、并设置了过期时间 key（4.0+版本支持）
具体使用哪种策略，我们需要根据具体的业务场景来配置。
一般最常使用的是 allkeys-lru / volatile-lru 淘汰策略，它们的处理逻辑是，每次从实例中随机取出一批 key（这个数量可配置），然后淘汰一个最少访问的 key，之后把剩下的 key 暂存到一个池子中，继续随机取一批 key，并与之前池子中的 key 比较，再淘汰一个最少访问的 key。以此往复，直到实例内存降到 maxmemory 之下。
针对这种情况，如何解决呢？
我给你 4 个方面的优化建议：
0. 避免存储 bigkey，降低释放内存的耗时
0. 淘汰策略改为随机淘汰，随机淘汰比 LRU 要快很多（视业务情况调整）
0. 拆分实例，把淘汰 key 的压力分摊到多个实例上
0. 如果使用的是 Redis 4.0 以上版本，开启 layz-free 机制，把淘汰 key 释放内存的操作放到后台线程中执行（配置 lazyfree-lazy-eviction = yes）
6. fork耗时严重
* * *
为了保证Redis数据安全性（持久化），我们可能会开启RDB和AOF 重写功能。但是往往在进行RDB和AOF 重写时，会导致其他客户端命令响应延迟增大。
当 Redis 开启了后台 RDB 和 AOF rewrite 后，在执行时，它们都需要主进程创建出一个子进程进行数据的持久化。主进程在创建子进程，会调用操作系统提供的fork函数，在fork过程中，主进程需要拷贝自己的内存页表给子进程，如果内存很大的话，这个过程是会比较耗时。
而且这个 fork 过程会消耗大量的 CPU 资源，在完成 fork 之前，整个 Redis 实例会被阻塞住，无法处理任何客户端请求。
如果此时你的 CPU 资源本来就很紧张，那么 fork 的耗时会更长，甚至达到秒级，这会严重影响 Redis 的性能。
那如何确认确实是因为 fork 耗时导致的 Redis 延迟变大呢？
你可以在 Redis 上执行 INFO 命令，查看 latest_fork_usec 项，单位微秒。这个时间就是主进程在 fork 子进程期间，整个实例阻塞无法处理客户端请求的时间。
要想避免这种情况，你可以采取以下方案进行优化：
0. 控制 Redis 实例的内存：尽量在 10G 以下，执行 fork 的耗时与实例大小有关，实例越大，耗时越久
0. 合理配置数据持久化策略：在 slave 节点执行 RDB 备份，推荐在低峰期执行，而对于丢失数据不敏感的业务（例如把 Redis 当做纯缓存使用），可以关闭 AOF 和 AOF rewrite
0. Redis 实例不要部署在虚拟机上：fork 的耗时也与系统也有关，虚拟机比物理机耗时更久
0. 降低主从库全量同步的概率：适当调大 repl-backlog-size 参数，避免主从全量同步
7. 开启AOF
* * *
上面我们分析了RDB和AOF 重写对redis性能的影响，主要体现在fork上。其实在redis持久化方面，还有影响redis 性能的因素，这次我们重点来看 AOF 数据持久化。
当redis开启了AOF后，工作流程如下：
0. Redis 执行写命令后，把这个命令写入到 AOF 文件内存中（write 系统调用）
0. Redis 根据配置的 AOF 刷盘策略，把 AOF 内存数据刷到磁盘上（fsync 系统调用）
redis提供了三种刷盘策略：
0. appendfsync always：主线程每次执行写操作后立即刷盘，此方案会占用比较大的磁盘 IO 资源，但数据安全性最高
0. appendfsync no：主线程每次写操作只写内存就返回，内存数据什么时候刷到磁盘，交由操作系统决定，此方案对性能影响最小，但数据安全性也最低，Redis 宕机时丢失的数据取决于操作系统刷盘时机
0. appendfsync everysec：主线程每次写操作只写内存就返回，然后由后台线程每隔 1 秒执行一次刷盘操作（触发fsync系统调用），此方案对性能影响相对较小，但当 Redis 宕机时会丢失 1 秒的数据
当AOF开启，选择了appendfsync always策略，每次写完后立马会进行刷盘，一方面会加大io的开销，另外加大redis响应延迟，操作磁盘要比操作内存慢几百倍，采用这个配置会严重拖慢 Redis 的性能，因此我不建议你把 AOF 刷盘方式配置为 always。
appendfsync no，对Redis性能友好，但是会造成数据丢失，对数据安全性不友好，一般不采取这种策略。
> 如果你的 Redis 只用作纯缓存，对于数据丢失不敏感，采用配置 appendfsync no 也是可以的。
看到这里，我猜你肯定和大多数人的想法一样，选比较折中的方案 appendfsync everysec 就没问题了吧？
这个方案优势在于，Redis 主线程写完内存后就返回，具体的刷盘操作是放到后台线程中执行的，后台线程每隔 1 秒把内存中的数据刷到磁盘中。
这种方案既兼顾了性能，又尽可能地保证了数据安全，是不是觉得很完美？
**但是，这里我要给你泼一盆冷水了，采用这种方案你也要警惕一下，因为这种方案还是存在导致 Redis 延迟变大的情况发生，甚至会阻塞整个 Redis。**
这是为什么？我把 AOF 最耗时的刷盘操作，放到后台线程中也会影响到 Redis 主线程？
你试想这样一种情况：当 Redis 后台线程在执行 AOF 文件刷盘时，如果此时磁盘的 IO 负载很高，那这个后台线程在执行刷盘操作（fsync系统调用）时就会被阻塞住。
此时的主线程依旧会接收写请求，紧接着，主线程又需要把数据写到文件内存中（write 系统调用），**但此时的后台子线程由于磁盘负载过高，导致 fsync 发生阻塞，迟迟不能返回，那主线程在执行 write 系统调用时，也会被阻塞住**，直到后台线程 fsync 执行完成后，主线程执行 write 才能成功返回。
所以，尽管你的 AOF 配置为 appendfsync everysec，也不能掉以轻心，要警惕磁盘压力过大导致的 Redis 有性能问题。
那什么情况下会导致磁盘 IO 负载过大？以及如何解决这个问题呢？
我总结了以下几种情况，你可以参考进行问题排查：
0. 子进程正在执行 AOF rewrite，这个过程会占用大量的磁盘 IO 资源
0. 有其他应用程序在执行大量的写文件操作，也会占用磁盘 IO 资源
对于情况1，说白了就是，Redis 的 AOF 后台子线程刷盘操作，撞上了子进程 AOF rewrite！
这怎么办？难道要关闭 AOF rewrite 才行？
幸运的是，Redis 提供了一个配置项，当子进程在 AOF rewrite 期间，可以让后台子线程不执行刷盘（不触发 fsync 系统调用）操作。
这相当于在 AOF rewrite 期间，临时把 appendfsync 设置为了 none，配置如下：
```
# AOF rewrite 期间，AOF 后台子线程不进行刷盘操作
# 相当于在这期间，临时把 appendfsync 设置为了 none
no-appendfsync-on-rewrite yes
```
当然，开启这个配置项，在 AOF rewrite 期间，如果实例发生宕机，那么此时会丢失更多的数据，性能和数据安全性，你需要权衡后进行选择。
如果占用磁盘资源的是其他应用程序，那就比较简单了，你需要定位到是哪个应用程序在大量写磁盘，然后把这个应用程序迁移到其他机器上执行就好了，避免对 Redis 产生影响。
当然，如果你对 Redis 的性能和数据安全都有很高的要求，那么我建议从**硬件层面**来优化，更换为 SSD 磁盘，提高磁盘的 IO 能力，保证 AOF 期间有充足的磁盘资源可以使用。
8. 使用swap
* * *
如果你发现 Redis 突然变得非常慢，**每次的操作耗时都达到了几百毫秒甚至秒级**，那此时你就需要检查 Redis 是否使用到了 Swap，在这种情况下 Redis 基本上已经无法提供高性能的服务了。
什么是 Swap？为什么使用 Swap 会导致 Redis 的性能下降？
如果你对操作系统有些了解，就会知道操作系统为了缓解内存不足对应用程序的影响，允许把一部分内存中的数据换到磁盘上，以达到应用程序对内存使用的缓冲，这些内存数据被换到磁盘上的区域，就是 Swap。
问题就在于，当内存中的数据被换到磁盘上后，Redis 再访问这些数据时，就需要从磁盘上读取，访问磁盘的速度要比访问内存慢几百倍！
**尤其是针对 Redis 这种对性能要求极高、性能极其敏感的数据库来说，这个操作延时是无法接受的。**
此时，你需要检查 Redis 机器的内存使用情况，确认是否存在使用了 Swap。
你可以通过以下方式来查看 Redis 进程是否使用到了 Swap：
```
# 先找到 Redis 的进程 ID
$ ps -aux | grep redis-server
# 查看 Redis Swap 使用情况
$ cat /proc/$pid/smaps | egrep '^(Swap|Size)'
```
输出结果如下：
```
Size: 1256 kB
Swap: 0 kB
Size: 4 kB
Swap: 0 kB
Size: 132 kB
Swap: 0 kB
Size: 63488 kB
Swap: 0 kB
Size: 132 kB
Swap: 0 kB
Size: 65404 kB
Swap: 0 kB
Size: 1921024 kB
Swap: 0 kB
...
```
这个结果会列出 Redis 进程的内存使用情况。
每一行 Size 表示 Redis 所用的一块内存大小，Size 下面的 Swap 就表示这块 Size 大小的内存，有多少数据已经被换到磁盘上了，如果这两个值相等，说明这块内存的数据都已经完全被换到磁盘上了。
如果只是少量数据被换到磁盘上，例如每一块 Swap 占对应 Size 的比例很小，那影响并不是很大。**如果是几百兆甚至上 GB 的内存被换到了磁盘上**，那么你就需要警惕了，这种情况 Redis 的性能肯定会急剧下降。
此时的解决方案是：
0. 增加机器的内存，让 Redis 有足够的内存可以使用
0. 整理内存空间，释放出足够的内存供 Redis 使用，然后释放 Redis 的 Swap，让 Redis 重新使用内存
释放 Redis 的 Swap 过程通常要重启实例，为了避免重启实例对业务的影响，一般会先进行主从切换，然后释放旧主节点的 Swap，重启旧主节点实例，待从库数据同步完成后，再进行主从切换即可。
可见，当 Redis 使用到 Swap 后，此时的 Redis 性能基本已达不到高性能的要求（你可以理解为武功被废），所以你也需要提前预防这种情况。
预防的办法就是，你需要对 Redis 机器的内存和 Swap 使用情况进行监控，在内存不足或使用到 Swap 时报警出来，及时处理。
9. 碎片整理
* * *
Redis 的数据都存储在内存中，当我们的应用程序频繁修改 Redis 中的数据时，就有可能会导致 Redis 产生内存碎片。
内存碎片会降低 Redis 的内存使用率，我们可以通过执行 INFO 命令，得到这个实例的内存碎片率：
```
# Memory
used_memory:5709194824
used_memory_human:5.32G
used_memory_rss:8264855552
used_memory_rss_human:7.70G
...
mem_fragmentation_ratio:1.45
```
这个内存碎片率是怎么计算的？
很简单，mem_fragmentation_ratio = used_memory_rss / used_memory。
其中 used_memory 表示 Redis 存储数据的内存大小，而 used_memory_rss 表示操作系统实际分配给 Redis 进程的大小。
如果 mem_fragmentation_ratio > 1.5，说明内存碎片率已经超过了 50%，这时我们就需要采取一些措施来降低内存碎片了。
解决的方案一般如下：
0. 如果你使用的是 Redis 4.0 以下版本，只能通过重启实例来解决
0. 如果你使用的是 Redis 4.0 版本，它正好提供了自动碎片整理的功能，可以通过配置开启碎片自动整理
**但是，开启内存碎片整理，它也有可能会导致 Redis 性能下降。**
原因在于，Redis 的碎片整理工作是也在**主线程**中执行的，当其进行碎片整理时，必然会消耗 CPU 资源，产生更多的耗时，从而影响到客户端的请求。
所以，当你需要开启这个功能时，最好提前测试评估它对 Redis 的影响。
你需要结合 Redis 机器的负载情况，以及应用程序可接受的延迟范围进行评估，合理调整碎片整理的参数，尽可能降低碎片整理期间对 Redis 的影响。
10. 网络带宽过载
* * *
如果以上产生性能问题的场景，你都规避掉了，而且 Redis 也稳定运行了很长时间，但在某个时间点之后开始，操作 Redis 突然开始变慢了，而且一直持续下去，这种情况又是什么原因导致？
此时你需要排查一下 Redis 机器的网络带宽是否过载，是否存在某个实例把整个机器的网路带宽占满的情况。
网络带宽过载的情况下，服务器在 TCP 层和网络层就会出现数据包发送延迟、丢包等情况。
Redis 的高性能，除了操作内存之外，就在于网络 IO 了，如果网络 IO 存在瓶颈，那么也会严重影响 Redis 的性能。
如果确实出现这种情况，你需要及时确认占满网络带宽 Redis 实例，如果属于正常的业务访问，那就需要及时扩容或迁移实例了，避免因为这个实例流量过大，影响这个机器的其他实例。
运维层面，你需要对 Redis 机器的各项指标增加监控，包括网络流量，在网络流量达到一定阈值时提前报警，及时确认和扩容。
总结
好了，上面就是我总结的在使用 Redis 过程中，常见的可能导致延迟、甚至阻塞的问题场景，以及如何快速定位和分析这些问题，并给出了针对性的解决方案。
参考：
黄健宏老师的《Redis设计与实现》
推荐阅读
招贤纳士
政采云技术团队（Zero），一个富有激情、创造力和执行力的团队，Base 在风景如画的杭州。团队现有 500 多名研发小伙伴，既有来自阿里、华为、网易的“老”兵，也有来自浙大、中科大、杭电等校的新人。团队在日常业务开发之外，还分别在云原生、区块链、人工智能、低代码平台、中间件、大数据、物料体系、工程平台、性能体验、可视化等领域进行技术探索和实践，推动并落地了一系列的内部技术产品，持续探索技术的新边界。此外，团队还纷纷投身社区建设，目前已经是 google flutter、scikit-learn、Apache Dubbo、Apache Rocketmq、Apache Pulsar、CNCF Dapr、Apache DolphinScheduler、alibaba Seata 等众多优秀开源社区的贡献者。如果你想改变一直被事折腾，希望开始折腾事；如果你想改变一直被告诫需要多些想法，却无从破局；如果你想改变你有能力去做成那个结果，却不需要你；如果你想改变你想做成的事需要一个团队去支撑，但没你带人的位置；如果你想改变本来悟性不错，但总是有那一层窗户纸的模糊……如果你相信相信的力量，相信平凡人能成就非凡事，相信能遇到更好的自己。如果你希望参与到随着业务腾飞的过程，亲手推动一个有着深入的业务理解、完善的技术体系、技术创造价值、影响力外溢的技术团队的成长过程，我觉得我们该聊聊。任何时间，等着你写点什么，发给 zcy-tc@cai-inc.com
微信公众号
文章同步发布，政采云技术团队公众号，欢迎关注
转载自:https://juejin.cn/post/7169375214344929288