宝刀未老？低代码何德何能受大厂们的推崇

Posted 2023-03-31 这我可不懂

风口之下，低代码蓬勃发展，本文从国内低代码的走红现象引入，浅析低代码发展中的变化趋势，重点探讨如此趋势之下，国内大厂如何通过低代码实现了良性发展。

一、国内爆火的低代码

据Gartner最新报告显示，到2023年，超过70%的企业将采用低代码作为他们发展战略的关键目标之一；到2025年，整体低代码开发平台市场规模将达到290亿美元，年复合增长率超过20%；

不仅如此，Gartner高级市场研究专家Varsha Mehta还预测：“企业组织越来越多地转向低代码开发技术，以满足对快速应用交付和高度定制的自动化工作流程不断增长的需求。”

这意味着，2023年，低代码将迎来高速增长。

低代码爆火的背后映照出来的，是企业迅速膨胀的数字化转型需求，企业需要通过数字化对流程进行简化科学管理，再加上疫情后的移动办公需求推动，低代码成为了解决这些难题的唯一答案。

二、大厂使用和推崇低代码

主要原因包括以下几点：

01、提高开发效率：

通过低代码平台，开发人员可以使用可视化拖拽的方式来创建应用，无需手动编写程序代码，从而大大提高了开发效率。同时，低代码平台还提供了丰富的组件库，包括UI组件、数据组件、业务组件等，使得开发人员可以更快地开发出功能完备的应用。

02、降低开发成本：

低代码平台可以自动生成大量的基础代码，并自动化处理许多开发任务，从而减少了开发人员的工作量和时间，降低了开发成本。此外，低代码平台还提供了多租户、自动伸缩、流水线部署等功能，进一步降低了运维成本。

03、增加业务灵活性：

企业的业务需求变化非常快，低代码平台提供了良好的扩展性和定制性，能够满足企业不断变化的业务需求。开发人员可以通过平台快速构建出不同的应用版本，以适应不同的业务场景。

04、加速数字化转型：

近年来，业界对数字化转型越来越重视。低代码平台可以帮助企业快速搭建数字化平台，提升企业数字化转型的速度和效率。同时，低代码平台还支持多种部署方案和移动端部署，使得企业可以更好地面向未来和面向客户。低代码体验：https://www.jnpfsoft.com/?csdn

三、低代码：朝着更好的未来前进

得益于行业的努力，低代码正朝着优质的方向前进。我们在讨论低代码的未来时，需要清楚一点的是，低代码并非万能，它有清晰的能力边界，而非一些声音所说的会“抢走程序员的饭碗”。

低代码是企业数字化建设当中“最后一公里”，在保障企业数字化进程的价值赋能下，中国市场已有低代码的一方天地。 国内的JNPF快速开发平台是一个低代码平台，除了满足上述功能作用，在应对复杂的业务需求也游刃有余，只需要会基本的sql语句和语法，就能进行快速开发。

综上所述，低代码开发平台在提高开发效率、降低开发成本、增加业务灵活性和加速数字化转型方面有着显著的优势，因此越来越多的大厂开始使用和推崇低代码开发平台。

史上最全，大厂们的那些Redis集群方案

1. 写在前面：

此文内容，来自于疯狂创客圈社群的面试交流：

为了给小伙伴释疑，架构师尼恩决定，将大厂的那些Redis集群方案，做一个大集合。

2. 业界主流的redis 集群方案

首先，来看看业界主流的Redis集群化方案，主要包括以下几个：

•客户端分片•代理分片•服务端分片

什么是代理分片，什么是 服务端分片, 说来话长，请参见文末的《Java面试红宝书》

3. 大厂们的 redis 集群方案

大厂的 redis 集群方案主要有两类：

•一是使用类 codis 的架构• 另一套基于官方的 redis cluster 的方案；

下面分别聊聊这两种方案；

4. 类 codis 架构

4.1 类 codis 架构的特点：

•分片算法：基于 slot hash桶；•分片实例之间相互独立，每组 一个master 实例和多个slave；•路由信息存放到第三方存储组件，如 zookeeper 或etcd•旁路组件探活

4.2 使用这套方案的大厂们，挺多的：

•阿里云•ApsaraCache•RedisLabs•京东•百度•等

codis架构中的slots 方案：

划分了 1024个slot， slots 信息在 proxy层感知；redis 进程中维护本实例上的所有key的一个slot map；

迁移过程中的读写冲突处理：

•最小迁移单位为key；•访问逻辑都是先访问 src 节点，再根据结果判断是否需要进一步访问 target 节点；•访问的 key 还未被迁移：读写请求访问 src 节点，处理后访问：•访问的 key 正在迁移：读请求访问 src 节点后直接返回；写请求无法处理，返回 retry•访问的 key 已被迁移(或不存在）：读写请求访问 src 节点，收到 moved 回复，继续访问 target 节点处理

阿里云

AparaCache 的单机版已开源(开源版本中不包含slot等实现)，集群方案细节未知；ApsaraCache^[1]

百度 BDRP 2.0

百度 BDRP 2.0主要组件：

proxy，基于twemproxy 改造，实现了动态路由表；redis内核：基于2.x 实现的slots 方案；metaserver：基于redis实现，包含的功能：拓扑信息的存储 & 探活；最多支持1000个节点；

slot 方案：

redis 内核中对db划分，做了16384个db；每个请求到来，首先做db选择；

数据迁移实现：

数据迁移的时候，最小迁移单位是slot，迁移中整个slot 处于阻塞状态，只支持读请求，不支持写请求；对比 官方 redis cluster/ codis 的按key粒度进行迁移的方案：按key迁移对用户请求更为友好，但迁移速度较慢；这个按slot进行迁移的方案速度更快；

京东

主要组件：

proxy: 自主实现，基于 golang 开发；redis内核：基于 redis 2.8 configServer(cfs)组件：配置信息存放；scala组件：用于触发部署、新建、扩容等请求；mysql：最终所有的元信息及配置的存储；sentinal（golang实现）：哨兵，用于监控proxy和redis实例，redis实例失败后触发切换；

slot 方案实现：

在内存中维护了slots的map映射表；

数据迁移：

基于 slots 粒度进行迁移；scala组件向dst实例发送命令告知会接受某个slot；dst 向 src 发送命令请求迁移，src开启一个线程来做数据的dump，将这个slot的数据整块dump发送到dst（未加锁，只读操作） 写请求会开辟一块缓冲区，所有的写请求除了写原有数据区域，同时双写到缓冲区中。当一个slot迁移完成后，把这个缓冲区的数据都传到dst，当缓冲区为空时，更改本分片slot规则，不再拥有该slot，后续再请求这个slot的key返回moved；上层proxy会保存两份路由表，当该slot 请求目标实例得到 move 结果后，更新拓扑；

跨机房：跨机房使用主从部署结构；没有多活，异地机房作为slave；

5 基于官方 redis cluster 的方案

和上一套方案比，所有功能都集成在 redis cluster 中，路由分片、拓扑信息的存储、探活都在redis cluster中实现；各实例间通过 gossip 通信；这样的好处是简单，依赖的组件少，应对400个节点以内的场景没有问题（按单实例8w read qps来计算，能够支持 200 * 8 = 1600w 的读多写少的场景）；但当需要支持更大的规模时，由于使用 gossip协议导致协议之间的通信消耗太大，redis cluster 不再合适；

使用这套方案的有：

•AWS•百度贴吧

官方 redis cluster

数据迁移过程：

• 基于 key粒度的数据迁移；•迁移过程的读写冲突处理：•从A 迁移到 B;•访问的 key 所属slot 不在节点 A 上时，返回 MOVED 转向，client 再次请求B；•访问的 key 所属 slot 在节点 A 上，但 key 不在 A上， 返回 ASK 转向，client再次请求B；•访问的 key 所属slot 在A上，且key在 A上，直接处理；（同步迁移场景：该 key正在迁移，则阻塞）

AWS ElasticCache

ElasticCache 支持主从和集群版、支持读写分离；集群版用的是开源的Redis Cluster，未做深度定制；

百度贴吧的ksarch-saas：

基于redis cluster + twemproxy 实现；后被 BDRP 吞并；twemproxy 实现了 smart client 功能；使用 redis cluster后还加一层 proxy的好处：

1.对client友好，不需要client都升级为smart client；（否则，所有语言client 都需要支持一遍）2.加一层proxy可以做更多平台策略；比如在proxy可做 大key、热key的监控、慢查询的请求监控、以及接入控制、请求过滤等；

即将发布的 redis 5.0 中有个 feature，作者计划给 redis cluster加一个proxy。

6 写在末尾

此文内容，收录入 《Java面试红宝石》。

史上最全面试宝典《Java面试红宝石》 免费领取

惊：书中题目，在面试中直接出现