其次是在调研阶段我们为什么选择了 Flink。在这个部分，主要是 Flink 与 Spark 的 structured streaming 的一些对比和选择 Flink 的原因。

根据CAP原理，分布式系统无法在保证了可用性（Availability）和分区容忍性（Partition）之后，继续保证一致性（Consistency）。我们认为，只要存在网络调用，就会存在调用失败的可能，系统之间必然存在着长或短的不一致状态。在服务化流行的今天，怎样及时发现系统服务间的不一致状态，以及怎样去量化衡量一个系统的数据...

有赞数据平台从2017年上半年开始，逐步使用 SparkSQL 替代 Hive 执行离线任务，目前 SparkSQL 每天的运行作业数量5000个，占离线作业数目的55%，消耗的 cpu 资源占集群总资源的50%左右。本文介绍由 SparkSQL 替换 Hive 过程中碰到的问题以及处理经验和优化建议，包括以下方面的内容：

HBase 是一个基于 Google BigTable 论文设计的高可靠性、高性能、可伸缩的分布式存储系统。 网上关于 HBase 的文章很多，官方文档介绍的也比较详细，本篇文章不介绍HBase基本的细节。

Gatling 是一个开源的基于 Scala、Akka、Netty 实现的高性能压测框架，较之其他基于线程实现的压测框架，Gatling 基于 AKKA Actor 模型实现，请求由事件驱动，在系统资源消耗上低于其他压测框架（如内存、连接池等），使得单台施压机可以模拟更多的用户。此外，Gatling 提供了一套简单高效的 DSL（领域特定语言）方便我...

一年以前，有赞准备在双十一到来之前对系统进行一次性能摸底，以便提前发现并解决系统潜在性能问题，好让系统在双十一期间可以从容应对剧增的流量。工欲善其事，必先利其器，我们拿什么工具来压测呢？我们做了很多前期调研和论证，最终决定基于 Gatling 开发有赞自己的分布式全链路压测引擎 —— MAXIM。一年多来，我们使...

有赞致力于成为商家服务领域里最被信任的引领者，因为被信任，所有我们更需要为商家保驾护航，保障系统的稳定性。有赞从去年开始通过全链路压测，模拟大促真实流量，串联线上全部系统，让核心系统同时达到流量峰值：

随着有赞支付体量的增大，资产部门承担的资金管理，风险把控的责任也越大。我们一方面要小步快跑，快速支撑业务，又要稳住底盘，守好底线。支付业务底线就是守护用户的每一分钱，不能有资金损失。在我们搭建这套体系前，有赞支付资金类的线上监控是个盲区，缺乏自我发现的能力。业务成功了，但内部对用户的资金操作可能...

容器化已经成为一种趋势，它可以解决很多运维中的痛点，比如效率、成本、稳定性等问题，而接入容器的过程中往往也会碰到很多问题和不便。在有赞最开始做容器化是为了快速交付开发测试环境，在容器化的过程中，我们碰到过容器技术、运维体系适配、用户使用习惯改变等各种问题，本文主要介绍有赞容器化过程中碰到的问题以...

H5 页面发版灵活，轻量，又具有跨平台的特性，在业务上有很多应用场景。但是同时对比 App，H5 的性能表现总是要逊色一筹，比如页面打开往往会出现白屏，滑动列表等交互场景下也不如 Native 页面流畅。针对这些白屏、卡慢之类的问题，我们测试该从哪些方面去展开测试分析和数据对比呢？接下来笔者分享一些 H5 前端测试实...