fix typo

go-zero.dev/cn/buiness-cache.md

@@ -50,7 +50,7 @@
 * 缓存完整信息
   
   ![biz-redis-01](./resource/biz-redis-01.svg)
-对发布的所有内容按照一定规则压缩后均进行存储，同样score我们还是用`createTime`毫秒值，这种存储方案的好处是业务的增、删、查、改均走reids，而db层这时候
+对发布的所有内容按照一定规则压缩后均进行存储，同样score我们还是用`createTime`毫秒值，这种存储方案的好处是业务的增、删、查、改均走redis，而db层这时候
 就可以不用考虑行记录缓存了，持久层仅提供数据备份和恢复使用，从另一方面来看，其缺点也很明显，需要的存储空间、配置要求更高，费用也会随之增大。
   
 示例代码：

go-zero.dev/en/buiness-cache.md

@@ -70,7 +70,7 @@ two redis storage schemes:
   ![biz-redis-01](./resource/biz-redis-01.svg)
   All published content will be stored after being compressed according to certain rules. For the same score, 
   we still use the `createTime` millisecond value. The advantage of this storage solution is that business additions, 
-  deletions, checks, and changes are all reids, while the db layer is at this time.
+  deletions, checks, and changes are all redis, while the db layer is at this time.
   
   You don’t need to consider the row record cache. The persistence layer only provides data backup and recovery. 
   On the other hand, its shortcomings are also obvious. The storage space and configuration requirements are higher, and the cost will increase.

website/docs/extension/buiness-cache.md

@@ -54,7 +54,7 @@ sidebar_position: 21
 * 缓存完整信息
   
   ![biz-redis-01](/img/biz-redis-01.png)
-对发布的所有内容按照一定规则压缩后均进行存储，同样score我们还是用`createTime`毫秒值，这种存储方案的好处是业务的增、删、查、改均走reids，而db层这时候
+对发布的所有内容按照一定规则压缩后均进行存储，同样score我们还是用`createTime`毫秒值，这种存储方案的好处是业务的增、删、查、改均走redis，而db层这时候
 就可以不用考虑行记录缓存了，持久层仅提供数据备份和恢复使用，从另一方面来看，其缺点也很明显，需要的存储空间、配置要求更高，费用也会随之增大。
   
 示例代码：

website/i18n/en/docusaurus-plugin-content-docs/current/extension/buiness-cache.md

@@ -54,7 +54,7 @@ sidebar_position: 21
 * 缓存完整信息
   
   ![biz-redis-01](/img/biz-redis-01.png)
-对发布的所有内容按照一定规则压缩后均进行存储，同样score我们还是用`createTime`毫秒值，这种存储方案的好处是业务的增、删、查、改均走reids，而db层这时候
+对发布的所有内容按照一定规则压缩后均进行存储，同样score我们还是用`createTime`毫秒值，这种存储方案的好处是业务的增、删、查、改均走redis，而db层这时候
 就可以不用考虑行记录缓存了，持久层仅提供数据备份和恢复使用，从另一方面来看，其缺点也很明显，需要的存储空间、配置要求更高，费用也会随之增大。
   
 示例代码：