保存成功
订阅成功
保存失败,请重试
提交成功
后端
千亿数据的潘多拉魔盒:从分库分表到分布式数据库
近年来,随着国内互联网行业的加速发展,以及摩尔定律的实效,千亿数据的潘多拉魔盒早已打开,传统的开源/商业关系数据库早已遇到了容量的瓶颈。而容量告警则不仅意味着业务发展收到影响,同时对现有系统的稳定性和可用性、可维护性,也带来极大的挑战。 从十年前起,淘宝等公司就遇到这类制约业务发展的技术问题,进而有了 TDDL 框架,2016 年当当网也发起了 Sharding-JDBC 项目,通过包装 JDBC,来屏蔽 MySQL 分库分表的逻辑,让业务系统想使用单机数据库一样方便。 后来,JDBC 封装框架逐渐演变到中间件,在 TDDL 的基础上,淘宝逐渐发展出来了 DRDS,在 Sharding-JDBC 转移到 Apache 和京东数科以后又孵化出来了 Sharding-Proxy,都是以一个虚拟的 MySQL Server 提供更透明和无侵入的客户端接入服务。其他的中间件,像 MyCat 和 DBLE 也方兴未艾。 另一方面,随着 Google 的 Spanner,阿里的 OceanBase 和 PolarDB,AWS 的 Aurora,PingCAP 的 TiDB,Cockroachlabs 的 CockroachDB 等商业或开源的技术作为代表,分布式数据库开始大规模兴起。这些技术试图通过一个直接的数据库来解决上述问题,而不仅仅是类库或中间件,这种增强 MySQL/PGSQL 的间接方式。当然,分布式数据库本身的复杂度,是另外一个话题。 以上种种对于企业来说,都是试图通过采用类似 Apache ShardingSphere 这种分布式的数据库中间件、或者 CockroachDB 这种分布式数据库作为整体解决方案,增强数据库的吞吐能力,保证高可用和实时强一致性的同时,实现线性的水平扩展能力,在一定规模上提升企业信息系统的数据管理上限。本文将从这个整体的发展过程谈起,详细介绍每一个阶段技术的特点、解决的问题,适用的场景,带领大家了解千亿数据的秘密。 计划写作大纲: - 从单机数据库讲起 - MySQL 的高可用与短板 - 分库分表的优势与陷阱 - 哪些场景下我们需要用分库分表 - 数据库中间件的技术选型 - 什么时候引入数据库中间件 - NoSQL 与 NewSQL - 当我们谈分布式数据库的时候,我们在谈什么 - 典型的几个分布式数据库
秦金卫(kimmking) · 高级技术总监
347 人已加入
前端
前端搞工程化:持续集成
你工作 1~3 年时, 三大框架都有接触过了,平常需求来了,都能很好的完成,感觉遇到瓶颈了,想做些提效的工具又不知道从哪下手,网上文章有泛泛而谈,看完也不知道咋下手 笔者在中台写前端,不夸张的说,写各种持续集成 CI 脚本快要写吐了,也给很多同事讲解过怎么样设计一套好用的 CI,还算比较有经验。能很好的梳理这些知识点,讲解清晰,通俗易懂的学会这些知识。网上这类文章都不集中,分散四处,不成体系,本次 Chat 的目的是,看完能在大脑形成一颗树状结构化知识 因为大部分公司一般都用 Gitlab,这里主要用 Gitlab CI 讲解,会提供能直接用的 Demo。 总之就是,看完能懂,懂完能抄,抄完能出成果。 在本场 Chat 中,会讲到如下内容: - 写 CI 难道真的是上来一个 npm i xxx-ci -g 么(最不喜欢就这种全局安装了,学习下 egg 优雅方式) - Gitlab-CI 简单介绍 - Gitlab Restful API 介绍 - 脚手架、本地创建项目 => 自动同步到 Gitlab - 单页应用 push => 打包构建 => 发布 => 接oss => 自动刷新cdn => 消息通知 - 多页应用、增量构建 - 微信小程序 push => 构建 => 上传,一条龙服务 - npm 组件,构建发布一条龙
hucheng · 高级前端工程师
199 人已加入
后端
系统上线后雪崩!让我来带你们学习 Spring Cloud Hystrix 及监控来解决雪崩问题
在如今随着网络及电商的发展,系统雪崩也是人们常遇到的问题,每年在年度大促时,总会有某个知名平台因此雪崩,我们传统的提前处理方法是,加机器加机器加机器,促销机器专用等等,事件发生时的处理方式是紧急召集一批人,处理数据的、处理业务的、处理部署架构的、等等整晚整晚紧急对应,很多时候还要申请一堆新机器,暂时把出了问题的机器切换掉,把应用修改,切换等等,耗时耗力不说,效果实在也是差强人意,经常还要听一大堆人的抱怨,“怎么还没好........",云云。 如今随着微服务的到来,Spring Cloud 可以非常快速、方便、有效的解决雪崩问题。 Spring Cloud 的熔断器会在自动侦测系统的错误,发现错误后,会强迫以后的访问快速失败,从而防止某个服务不断地尝试执行会失败的操作,它会使服务继续执行而不用等待修正错误,或者浪费 CPU 时间去等到超时产生。熔断器也可以使服务能够诊断错误是否已经修正,如果已经修正,服务会再次尝试调用操作。 本课程就带领大家来实践一下 Spring Cloud 的熔断器及熔断监控。 本场 Chat 包含如下内容: - 使用 Spring Cloud 创建注册中心 - 加入提供服务者、及消费者模块 - 加入熔断器设定 - 单个应用加入熔断监控 - 为整个项目加入熔断器监控 本场 Chat 适用于: - 希望学习了解熔断器及监控来解决雪崩问题的人员 - 任何希望了解、学习 Spring Cloud 的人员 - 希望从事 Java 相关工作的人员
IT职涯 · 架构师
166 人已加入
微信扫描登录