DataWorks和DataOne比较

Redis数据库和DataWorks

---

Redis简介

Redis是一个数据库，不过与传统数据库不同的是Redis的数据库是存在内存中，所以读写速度非常快，因此 Redis被广泛应用于缓存方向。

除此之外，Redis也经常用来做分布式锁，Redis提供了多种数据类型来支持不同的业务场景。除此之外，Redis 支持事务持久化、LUA脚本、LRU驱动事件、多种集群方案。

Redis五种数据类型

简单动态字符串(Simple Dynamic String，SDS)

Redis没有直接使用C语言传统的字符串，而是自己构建了一种名为简单动态字符串（Simple dynamic string，SDS）的抽象类型，并将SDS用作Redis的默认字符串表示。

其实SDS等同于C语言中的char * ，但它可以存储任意二进制数据，不能像C语言字符串那样以字符’\0’来标识字符串的结 束，因此它必然有个长度字段。

1.定义

struct sdshdr {
// 记录buf数组中已使用字节的数量
// 等于sds所保存字符串的长度
int len;

// 记录buf数组中未使用字节的数量
int free;

// 字节数组，用于保存字符串
char buf[];}

2.优点

• 获取字符串长度的复杂度为O(1)。
• 杜绝缓冲区溢出。
• 减少修改字符串长度时所需要的内存重分配次数。
• 二进制安全。
• 兼容部分C字符串函数。

它具有很常规的 set/get 操作，value 可以是String也可以是数字，一般做一些复杂的计数功能的缓存。

DataWorks

1. 认清自身

DataWorks研发平台属于典型的PaaS应用，当然也有数据服务这样的产品做到了SaaS层。传统SOA遇到的痛点，以及将来我们要对客户开放的定制化能力，需要借助微服务架构来应对，逐步将研发重心从PaaS移向SaaS。

当我们采用基于K8S容器化的微服务架构之后，开发者可以在我们自主研发的微服务平台中集成DataWorks平台开放出来的基础OpenAPI，也可以集成外部应用的API，在微服务中进行数据整合和业务逻辑的编写，最终暴露出一系列在平台前端可访问的API，供前端功能模块使用。在这个过程中，我们可以顺便化解前文提到的一些痛点。

2. 需求痛点

以历史包袱为例，我们可以逐步将年久失修的，陈旧的SOA单体服务中包含的功能进行替换，将这个快变质的大饼切割成一个个低耦合的小饼，实现逐步的更替，而非采用长周期的一次性整体替换。陈旧的工程不必再去发展更新，仅维持基本的运行，避免了整体替换带来的周期长，故障多，回滚困难的问题。而且我们可以很方便的通过金丝雀发布来验证新上的“小饼”是否成功替代了“变质大饼”中一小部分模块的功能，通过蓝绿部署将有问题的小饼快速及时的撤下，也可以做到通过ABTest来验证哪块小饼的性能更好、设计更合理。

再以个性化需求为例，当我们开放了和DataWorks业务耦合的微服务平台，具备自研能力的业务团队（如数据/报表开发团队）就可以借助微服务的设计，快速的将自己的需求设计到我们DataWorks平台后端，同时前端页面我们也会留出“自留地”（下文描述的插件化）供业务团队自行设计开发。引擎的接入同样可以参照此模式进行，DataWorks下一部分模块的接入可以更加的傻瓜化，比如检查器，比如功能强大的自定义节点等，用户根据文档经过简单的开发后就可以快速自主接入使用，但对于更加订制的功能，例如当前ADB引擎正在DataWorks平台上进行的可视化建表部分的设计，由于复杂度很高，因此必须通过微服务对接前端插槽（下文描述）来进行开发，从而实现复杂业务逻辑的自主自助接入。

再来描述一下基于架构的灰度机制，在微服务架构下，可以轻松的实现蓝绿部署，金丝雀发布和ABTest，我们的微服务设计应该是尽量面向领域的（当然不太可能做到100%的面向领域），高内聚低耦合依然是单个微服务的设计宗旨。我们可以发布多个版本的微服务用来测试某个领域的问题是否得到某方面的改善，也可以发布多个完全基于不同框架甚至是不同语言设计的微服务，来验证某个领域内谁是最优解。借助于基于架构的灰度机制，基于云原生，这一切都将非常高效且可靠，即使出现问题，也可以快速撤下有问题的微服务，避免扩大影响。

还有其他一些痛点，不一一描述基于微服务架构的解法，比如牵一发而动全身的问题，在DataWorks平台全面构建到微服务架构上之后，这个问题自然就会消失。每个同学都可以分管多个面向领域的足够小的微服务，当某个接口需要重新设计，不必立即替换老的接口，而可以将这个接口下对应的微服务低成本的重新设计，等待流量切换到新的微服务后，再逐步下线旧版本微服务。再比如SpringBoot下由Starter引入的耦合性，到了微服务框架下，将会通过服务发现来解耦，不再需要通过代码层面的依赖来耦合关联。