Author: leelight

[转]分库分表无限扩容 0

[转]分库分表无限扩容

正常情况下的服务演化之路 让我们从最初开始。 1、单体应用 每个创业公司基本都是从类似 SSM 和 SSH 这种架构起来的,没什么好讲的,基本每个程序员都经历过。 2、RPC 应用 当业务越来越大,我们需要对服务进行水平扩容,扩容很简单,只要保证服务是无状态的就可以了,如下图: 当业务又越来越大,我们的服务关系错综复杂,同时,有很多服务访问都是不需要连接 DB 的,只需要连接缓存即可,那么就可以做成分离的,减少 DB 宝贵的连接。如下图: 我相信大部分公司都是在这个阶段。Dubbo 就是为了解决这个问题而生的。 3、分库分表 如果你的公司产品很受欢迎,业务继续高速发展,数据越来越多,SQL 操作越来越慢,那么数据库就会成为瓶颈,那么你肯定会想到分库分表,不论通过 ID hash 或者 range 的方式都可以。如下图: 这下应该没问题了吧。任凭你用户再多,并发再高,我只要无限扩容数据库,无限扩容应用,就可以了。 这也是本文的标题,分库分表就能解决无限扩容吗? 实际上,像上面的架构,并不能解决。 其实,这个问题和 RPC 的问题有点类似:数据库连接过多!!! 通常,我们的 RPC...

[转]跨库分页的几种常见方案 0

[转]跨库分页的几种常见方案

为什么需要研究跨库分页? 互联网很多业务都有分页拉取数据的需求,例如: (1)微信消息过多时,拉取第N页消息; (2)京东下单过多时,拉取第N页订单; (3)浏览58同城,查看第N页帖子; Please follow and like us:0

[转]MySQL 备份恢复 0

[转]MySQL 备份恢复

MySQL 备份恢复(一) mysqldump MySQL 备份恢复(二) select …… into outfile MySQL 备份恢复(三) mydumper MySQL 备份恢复(四) XtraBackup   Please follow and like us:0

[转]1万属性,100亿数据,每秒10万吞吐,架构如何设计? 0

[转]1万属性,100亿数据,每秒10万吞吐,架构如何设计?

有一类业务场景,没有固定的schema存储,却有着海量的数据行数,架构上如何来实现这类业务的存储与检索呢?58最核心的数据“帖子”的架构实现技术细节,今天和大家聊一聊。 一、背景描述及业务介绍 什么是58最核心的数据? 58是一个信息平台,有很多垂直品类:招聘、房产、二手物品、二手车、黄页等等,每个品类又有很多子品类,不管哪个品类,最核心的数据都是“帖子信息”。 画外音:像不像一个大论坛? Please follow and like us:0

[转]分库分表如何做到永不迁移数据和避免热点? 0

[转]分库分表如何做到永不迁移数据和避免热点?

一、前言 中大型项目中,一旦遇到数据量比较大,小伙伴应该都知道就应该对数据进行拆分了。有垂直和水平两种。 Please follow and like us:0

[转]acks参数对消息持久化的影响 0

[转]acks参数对消息持久化的影响

(0)写在前面  面试大厂时,一旦简历上写了Kafka,几乎必然会被问到一个问题:说说acks参数对消息持久化的影响? 这个acks参数在kafka的使用中,是非常核心以及关键的一个参数,决定了很多东西。 所以无论是为了面试还是实际项目使用,大家都值得看一下这篇文章对Kafka的acks参数的分析,以及背后的原理。 Please follow and like us:0

[转]全文搜索引擎选 ElasticSearch 还是 Solr? 0

[转]全文搜索引擎选 ElasticSearch 还是 Solr?

最近项目组安排了一个任务,项目中用到了全文搜索,基于全文搜索 Solr,但是该 Solr 搜索云项目不稳定,经常查询不出来数据,需要手动全量同步,而且是其他团队在维护,依赖性太强,导致 Solr 服务一出问题,我们的项目也基本瘫痪,因为所有的依赖查询都无结果数据了。所以考虑开发一个适配层,如果 Solr 搜索出问题,自动切换到新的搜索–ES。 其实可以通过 Solr 集群或者服务容错等设计来解决该问题。但是先不考虑本身设计的合理性,领导需要开发,所以我开始踏上了搭建 ES 服务的道路,从零开始,因为之前完全没接触过 ES,所以通过本系列来记录下自己的开发过程。 Please follow and like us:0

[转]云平台 Linux 服务器问题场景分析思路及工具箱 0

[转]云平台 Linux 服务器问题场景分析思路及工具箱

作者整理了云平台 Linux 服务器(下文中区分了物理机及虚拟机)运维中的常见问题场景、分析工具箱及判别思路,主要针对中高级 linux 服务器运维人员。 Please follow and like us:0