![](https://img-blog.csdnimg.cn/20201014180756927.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
架构师之路
痞子锐
逆水行舟 不进则退
展开
-
网站性能优化实战
网站性能优化实战——从12.67s到1.06s的故事JAVA高级架构 昨天网站性能监测与优化策略0.引言作为互联网项目,最重要的便是用户体验。在举国“互联网+”的热潮中,用户至上也已经被大多数企业所接收,特别是在如今移动端快速发展的时代,我们的网页不仅只是呈现在用户的PC浏览器里,更多的时候,用户是通过移动产品浏览我们的网页。加之有越来越多的开发者投入到Web APP和Hybrid APP的开发队...转载 2018-05-31 08:46:48 · 1768 阅读 · 0 评论 -
微信为啥不丢“离线消息”?
需求缘起当发送方用户A发送消息给接收方用户B时,如果用户B在线,之前的文章《微信为啥不丢“在线消息”?》聊过,可以通过应用层的确认,发送方的超时重传,接收方的去重保证业务层面消息的不丢不重。那如果接收方用户B不在线,系统是如何保证消息的可达性的呢?这是本文要讨论的问题。 问题:接收方不在线时,消息发送的流程是怎么样的?回答:如上图所述,(1)转载 2018-01-13 13:48:50 · 462 阅读 · 0 评论 -
微信多点登录与QQ消息漫游架构随想
【需求缘起】之前的一些文章简单介绍了《“单人消息”》《“离线消息”》《“群消息”》《“用户状态”》的一些相关技术(点击上面的link直接阅读),今天来聊一聊“多点登陆”与“消息漫游”。提问:什么是多点登录?回答:以微信为例,可以PC端,phone端同时登录,同时收发消息。需要注意的是,一个端只能登录一个实例,例如同一个QQ号,在pc1上登录,再到转载 2018-01-13 13:48:26 · 389 阅读 · 0 评论 -
群消息这么复杂,怎么能做到不丢不重?
【需求缘起】之前的文章更多的聊了单对单的消息投递:《微信为什么不丢消息?》《http如何像tcp一样实时的收消息?》群聊是多人社交的基本诉求,不管是QQ群,还是微信群,一个群友在群内发了一条消息:(1)在线的群友能第一时间收到消息(2)离线的群友能在登陆后收到消息由于“消息风暴扩散系数”的存在(概念详见《QQ状态同步究竟是推还转载 2018-01-13 13:48:05 · 235 阅读 · 0 评论 -
微服务架构之RPC-client序列化细节
第一章聊了【“为什么要进行服务化,服务化究竟解决什么问题”】第二章聊了【“微服务的服务粒度选型”】上一篇聊了【“为什么说要搞定微服务架构,先搞定RPC框架?”】通过上篇文章的介绍,知道了要实施微服务,首先要搞定RPC框架,RPC框架的职责要向【调用方】和【服务提供方】屏蔽各种复杂性:(1)让调用方感觉就像调用本地函数一样(2)让服务提供方感觉就像转载 2018-01-13 13:47:35 · 484 阅读 · 0 评论 -
单点系统架构的可用性与性能优化
一、需求缘起明明架构要求高可用,为何系统中还会存在单点?回答:单点master的设计,会大大简化系统设计,何况有时候避免不了单点 在哪些场景中会存在单点?先来看一下一个典型互联网高可用架构。典型互联网高可用架构:(1)客户端层,这一层是浏览器或者APP,第一步先访问DNS-server,由域名拿到nginx的外网IP(2)负载均衡层,ng转载 2018-01-13 13:47:20 · 172 阅读 · 0 评论 -
58到家通用实时消息平台架构细节(Qcon2016)
一、解决什么问题 + 难点解决什么业务问题(1)端到云的实时上报需求:58速运司机端GPS实时上报(2)云到端的实时推送需求:58速运司机订单实时推送(3)端到端的聊天消息需求:用户、商户、客服之间的聊天沟通难点:(1)APP无线环境下消息可达性(2)通用性,平台实现尽量与业务解耦二、传统解决方案与潜在不足【端转载 2018-01-13 13:47:00 · 238 阅读 · 0 评论 -
微信为啥这么省流量?
一、报文类型im的客户端与服务器通过发送报文(也就是网络包)来完成消息的传递,报文分为三种请求报文(request,后简称为为R)应答报文(acknowledge,后简称为A)通知报文(notify,后简称为N),这三种报文的解释如下:R:客户端主动发送给服务器的报文A:服务器被动应答客户端的报文,一个A对应一个RN:服务器主动发送给客户端的报文转载 2018-01-13 13:46:40 · 240 阅读 · 0 评论 -
应用层/安全层/传输层如何进行协议选型?
架构师之路系统设计,协议先行。大部分技术人没有接触协议的设计细节,更多的是使用已有协议进行应用层的编码,例如:(1)使用http作为载体,设计get/post/cookie参数(2)使用dubbo框架,而不用去深究内部的二进制包头包体,以及序列号反序列化的细节无论如何,了解协议设计的原则,对深入理解系统通信非常有帮助。今天就以即时转载 2018-01-13 13:46:03 · 441 阅读 · 0 评论 -
多库多事务降低数据不一致概率
一、案例缘起我们经常使用事务来保证数据库层面数据的ACID特性。举个栗子,用户下了一个订单,需要修改余额表,订单表,流水表,于是会有类似的伪代码:start transaction; CURDtable t_account; any Exception rollback; CURDtable t_order; a转载 2017-12-14 09:35:03 · 119 阅读 · 0 评论 -
啥,又要为表增加一列属性?
需求缘起产品第一版:用户有用户名、密码、昵称等三个属性,对应表设计:user(uid, name, passwd, nick)第二版,产品经理增加了年龄,性别两个属性,表结构可能要变成:user(uid, name, passwd, nick, age, sex)假设数据量和并发量比较大,怎么变?(1)alter table add转载 2017-12-14 09:37:30 · 166 阅读 · 0 评论 -
这才是真正的表扩展方案
事情变得有意思了,上一篇花1小时撰写的“一分钟”文章,又引起了广泛的讨论,说明相关的技术大家感兴趣,挺好。第一次一篇技术文章的评论量过100,才知道原来“评论精选”还有100上限,甚为欣慰(虽然是以一种自己不愿看到的方式)。 《啥,又要为表增加一列属性?》的方案颇有争议:(1)版本号version + 扩展字段ext(2)用增加列的key+value方式扩充属性转载 2017-12-14 09:37:56 · 164 阅读 · 0 评论 -
一分钟掌握数据库垂直拆分
一、缘起当数据库的数据量非常大时,水平切分和垂直拆分是两种常见的降低数据库大小,提升性能的方法。假设有用户表:user(uid bigint,name varchar(16),pass varchar(16),age int,sex tinyint,flag tinyint,sign varchar(64),intro转载 2017-12-14 09:38:30 · 154 阅读 · 0 评论 -
QQ状态同步究竟是推还是拉?
前面两篇讲即时通讯核心技术的文章《微信为什么不丢消息?》《http如何像tcp一样实时的收消息?》反馈还可以,故继续即时通讯这一个系列吧,今天聊聊即时通讯中的“状态”。需求缘起“在线状态一致性”(好友在线状态,群友在线状态)是即时通讯领域较难解决的一个技术问题,如何精准实时的获得好友、群友的在线状态,是今天将要探讨的话题。好友转载 2017-12-14 09:23:58 · 174 阅读 · 0 评论 -
主从DB与cache一致性
本文主要讨论这么几个问题:(1)数据库主从延时为何会导致缓存数据不一致(2)优化思路与方案 一、需求缘起上一篇《缓存架构设计细节二三事》中有一个小优化点,在只有主库时,通过“串行化”的思路可以解决缓存与数据库中数据不一致。引发大家热烈讨论的点是“在主从同步,读写分离的数据库架构下,有可能出现脏数据入缓存的情况,此时串行化方案不再适用了”,这就是本文要讨论的主转载 2017-12-14 09:33:37 · 126 阅读 · 0 评论 -
微信为什么不丢消息?
一、报文类型im的客户端与服务器通过发送报文(也就是网络包)来完成消息的传递,报文分为三种请求报文(request,后简称为为R)应答报文(acknowledge,后简称为A)通知报文(notify,后简称为N),这三种报文的解释如下:R:客户端主动发送给服务器的报文A:服务器被动应答客户端的报文,一个A对应一个RN:服务器主动发送给客户端的报文转载 2018-01-16 11:18:51 · 186 阅读 · 0 评论 -
RPC-client异步收发核心细节?
第一章聊了【“为什么要进行服务化,服务化究竟解决什么问题”】第二章聊了【“微服务的服务粒度选型”】第三章聊了【“为什么说要搞定微服务架构,先搞定RPC框架?”】上一章聊了【“微服务架构之RPC-client序列化细节”】通过上篇文章的介绍,知道了要实施微服务,首先要搞定RPC框架,RPC框架分为客户端部分与服务端部分。RPC-client的部转载 2018-01-16 11:19:09 · 336 阅读 · 0 评论 -
DB主从一致性架构优化4种方法
需求缘起大部分互联网的业务都是“读多写少”的场景,数据库层面,读性能往往成为瓶颈。如下图:业界通常采用“一主多从,读写分离,冗余多个读库”的数据库架构来提升数据库的读性能。这种架构的一个潜在缺点是,业务方有可能读取到并不是最新的旧数据:(1)系统先对DB-master进行了一个写操作,写主库(2)很短的时间内并发进行了一个读操作,读从库,此时主从同步没有完成转载 2018-01-08 09:18:25 · 122 阅读 · 0 评论 -
一分钟了解负载均衡的一切
什么是负载均衡负载均衡(Load Balance)是分布式系统架构设计中必须考虑的因素之一,它通常是指,将请求/数据【均匀】分摊到多个操作单元上执行,负载均衡的关键在于【均匀】。 常见的负载均衡方案常见互联网分布式架构如上,分为客户端层、反向代理nginx层、站点层、服务层、数据层。可以看到,每一个下游都有多个上游调用,只需要做到,每一个上游都均匀访问每一个下游,就能实现“将请求/数据【均匀】分摊转载 2018-01-19 14:48:20 · 197 阅读 · 0 评论 -
如何实施异构服务器的负载均衡及过载保护?
零、需求缘起第一篇文章“一分钟了解负载均衡”和大家share了互联网架构中反向代理层、站点层、服务层、数据层的常用负载均衡方法。第二篇文章“lvs为何不能完全代替DNS轮询”和大家share了互联网接入层负载均衡需要解决的问题及架构演进。在这两篇文章中,都强调了“负载均衡是指,将请求/数据【均匀】分摊到多个操作单元上执行,负载均衡的关键在于【均匀】”。然而,后端的service有可能部署在硬件条件转载 2018-01-19 14:48:16 · 225 阅读 · 0 评论 -
lvs为何不能完全替代DNS轮询
上一篇文章“一分钟了解负载均衡的一切”引起了不少同学的关注,评论中大家争论的比较多的一个技术点是接入层负载均衡技术,部分同学持这样的观点:1)nginx前端加入lvs和keepalived可以替代“DNS轮询”2)F5能搞定接入层高可用、扩展性、负载均衡,可以替代“DNS轮询”“DNS轮询”究竟是不是过时的技术,是不是可以被其他方案替代,接入层架构技术演进,是本文将要细致讨论的内容。 一、问题域n转载 2018-01-19 14:48:09 · 157 阅读 · 0 评论 -
究竟啥才是互联网架构“高并发”
一、什么是高并发高并发(High Concurrency)是互联网分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计保证系统能够同时并行处理很多请求。高并发相关常用的一些指标有响应时间(Response Time),吞吐量(Throughput),每秒查询率QPS(Query Per Second),并发用户数等。响应时间:系统对请求做出响应的时间。例如系统处理一个HTTP请求需要200转载 2018-01-19 14:48:02 · 214 阅读 · 0 评论 -
究竟啥才是互联网架构“高可用”
一、什么是高可用高可用HA(High Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计减少系统不能提供服务的时间。假设系统一直能够提供服务,我们说系统的可用性是100%。如果系统每运行100个时间单位,会有1个时间单位无法提供服务,我们说系统的可用性是99%。很多公司的高可用目标是4个9,也就是99.99%,这就意味着,系统的年停机时间为8.76个小时。百度转载 2018-01-19 14:47:56 · 197 阅读 · 0 评论 -
100亿数据1万属性数据架构设计
一、背景描述及业务介绍问:什么是数据库扩展的version + ext方案?使用ext来承载不同业务需求的个性化属性,使用version来标识ext里各个字段的含义。例如上述user表:verion=0表示ext里是passwd/nickversion=1表示ext里是passwd/nick/age/sex 优点?(1)可以随时动态扩展属性,扩展性好(2)新旧两种数据可以同时存在,兼容性好不足?(转载 2018-01-19 14:47:46 · 191 阅读 · 0 评论 -
互联网架构为什么要做服务化?
一、互联网高可用架构,为什么要服务化?【服务化之前高可用架构】在服务化之前,互联网的高可用架构大致是这样一个架构:(1)用户端是浏览器browser,APP客户端(2)后端入口是高可用的nginx集群,用于做反向代理(3)中间核心是高可用的web-server集群,研发工程师主要编码工作就是在这一层(4)后端存储是高可用的db集群,数据存储在这一层 更典型的,web-server层是通过DAO/O转载 2018-01-19 14:47:33 · 137 阅读 · 0 评论 -
微服务架构多“微”才合适?
前情提要:互联网架构为什么要做服务化?一、互联网架构为什么要进行服务化-总结上一篇和大伙交流了一下,随着数据量、并发量、业务复杂度的增长,互联网架构会出现以下问题:(1)代码到处拷贝(2)底层复杂性扩散(3)基础库(so/jar/dll)耦合(4)SQL质量得不到保障,业务相互影响(5)数据库耦合“服务化”是一个很好的解决上述痛点的方案。 不少评论也提出了不少有建设性的观点,汇总出来分享给大伙:@转载 2018-01-19 14:47:27 · 255 阅读 · 0 评论 -
为什么说要搞定微服务架构,先搞定RPC框架?
今天开始聊一些微服务的实践,第一块,RPC框架的原理及实践,为什么说要搞定微服务架构,先搞定RPC框架呢?一、需求缘起服务化的一个好处就是,不限定服务的提供方使用什么技术选型,能够实现大公司跨团队的技术解耦,如下图:服务A是欧洲团队提供服务,欧洲团队的技术背景是Java,可以用Java实现服务;服务B是美洲团队提供服务,可以用C++实现服务;服务C是中国团队提供服务,可以用Go实现服务;服务的上游转载 2018-01-19 14:47:21 · 236 阅读 · 0 评论 -
http如何像tcp一样实时的收消息?
http如何像tcp一样实时的收消息?一、webim如何实现消息推送webim通常有三种方式实现推送通道:1)WebSocket2)FlashSocket3)http轮询其中1)和2)是用Tcp长连接实现的,其消息的实时性可以通过tcp保证。方案3)才算是webim实现消息推送的“正统”方案,用http短连接轮询的方式实现“伪长连接”,既然是轮询,有朋友转载 2018-01-08 09:50:07 · 180 阅读 · 0 评论 -
数据库软件架构设计些什么
缘起:受@萧田国 萧总邀请,上周五晚上在“高效运维1号群”内分享了《58同城数据库软件架构设计与实践》(这个topic今年在数据库大会上分享过),应组织方要求,发出纪要。一、基本概念二、数据库架构设计思路(1)可用性(2)读性能(3)一致性(4)扩展性一、基本概念概念一“单库”转载 2018-01-08 09:49:53 · 220 阅读 · 0 评论 -
缓存架构设计细节二三事
本文主要讨论这么几个问题:(1)“缓存与数据库”需求缘起(2)“淘汰缓存”还是“更新缓存”(3)缓存和数据库的操作时序(4)缓存和数据库架构简析 一、需求缘起场景介绍缓存是一种提高系统读性能的常见技术,对于读多写少的应用场景,我们经常使用缓存来进行优化。例如对于用户的余额信息表account(uid, money),业务上转载 2018-01-08 09:27:48 · 191 阅读 · 0 评论 -
细聊冗余表数据一致性(架构师之路)
本文主要讨论四个问题:(1)为什么会有冗余表的需求(2)如何实现冗余表(3)正反冗余表谁先执行(4)冗余表如何保证数据的一致性 一、需求缘起互联网很多业务场景的数据量很大,此时数据库架构要进行水平切分,水平切分会有一个patition key,通过patition key的查询能够直接定位到库,但是非patition key上的查询可能就转载 2018-01-08 09:19:11 · 218 阅读 · 0 评论 -
缓存与数据库一致性保证
本文主要讨论这么几个问题:(1)啥时候数据库和缓存中的数据会不一致(2)不一致优化思路(3)如何保证数据库与缓存的一致性 一、需求缘起上一篇《缓存架构设计细节二三事》(点击查看)引起了广泛的讨论,其中有一个结论:当数据发生变化时,“先淘汰缓存,再修改数据库”这个点是大家讨论的最多的。上篇文章得出这个结论的依据是,由于操作缓存与操作转载 2018-01-08 09:18:55 · 235 阅读 · 0 评论 -
数据库秒级平滑扩容架构方案
一、缘起(1)并发量大,流量大的互联网架构,一般来说,数据库上层都有一个服务层,服务层记录了“业务库名”与“数据库实例”的映射关系,通过数据库连接池向数据库路由sql语句以执行:如上图:服务层配置用户库user对应的数据库实例物理位置为ip(其实是一个内网域名)。 (2)随着数据量的增大,数据要进行水平切分,分库后将数据分布到不同的数据库实例(甚至物理机器)转载 2017-12-14 09:39:04 · 265 阅读 · 0 评论 -
消息“时序”与“一致性”为何这么难?
分布式系统中,很多业务场景都需要考虑消息投递的时序,例如:(1)单聊消息投递,保证发送方发送顺序与接收方展现顺序一致(2)群聊消息投递,保证所有接收方展现顺序一致(3)充值支付消息,保证同一个用户发起的请求在服务端执行序列一致消息时序是分布式系统架构设计中非常难的问题,ta为什么难,有什么常见优化实践,是本文要讨论的问题。 一、为什么时序难以保证,消转载 2017-12-14 09:24:33 · 410 阅读 · 0 评论 -
mysql并行复制降低主从同步延时的思路与启示
一、缘起mysql主从复制,读写分离是互联网用的非常多的mysql架构,主从复制最令人诟病的地方就是,在数据量较大并发量较大的场景下,主从延时会比较严重。 为什么mysql主从延时这么大?回答:从库使用【单线程】重放relaylog。 优化思路是什么?回答:使用单线程重放relaylog使得同步时间会比较久,导致主从延时很长,优化思路不难转载 2017-12-14 09:35:37 · 895 阅读 · 0 评论 -
线程数究竟设多少合理
一、需求缘起Web-Server通常有个配置,最大工作线程数,后端服务一般也有个配置,工作线程池的线程数量,这个线程数的配置不同的业务架构师有不同的经验值,有些业务设置为CPU核数的2倍,有些业务设置为CPU核数的8倍,有些业务设置为CPU核数的32倍。“工作线程数”的设置依据是什么,到底设置为多少能够最大化CPU性能,是本文要讨论的问题。 二、一些共性认知转载 2017-12-14 09:00:16 · 179 阅读 · 0 评论 -
细聊分布式ID生成方法
一、需求缘起几乎所有的业务系统,都有生成一个记录标识的需求,例如:(1)消息标识:message-id(2)订单标识:order-id(3)帖子标识:tiezi-id这个记录标识往往就是数据库中的唯一主键,数据库上会建立聚集索引(cluster index),即在物理存储上以这个字段排序。 这个记录标识上的查询,往往又有分页或者排序的业务转载 2017-12-14 08:54:02 · 159 阅读 · 0 评论 -
互联网架构,如何进行容量设计?
一,需求缘起互联网公司,这样的场景是否似曾相识: 场景一:pm要做一个很大的运营活动,技术老大杀过来,问了两个问题:(1)机器能抗住么?(2)如果扛不住,需要加多少台机器? 场景二:系统设计阶段,技术老大杀过来,又问了两个问题:(1)数据库需要分库么?(2)如果需要分库,需要分几个库? 技术上来说,这些都是系统转载 2017-12-14 08:53:12 · 382 阅读 · 0 评论 -
秒杀系统架构优化思路
一、秒杀业务为什么难做1)im系统,例如qq或者微博,每个人都读自己的数据(好友列表、群列表、个人信息);2)微博系统,每个人读你关注的人的数据,一个人读多个人的数据;3)秒杀系统,库存只有一份,所有人会在集中的时间读和写这些数据,多个人读一个数据。 例如:小米手机每周二的秒杀,可能手机只有1万部,但瞬时进入的流量可能是几百几千万。又例如:12306转载 2017-12-14 08:51:52 · 137 阅读 · 0 评论 -
java面试题
经常面试一些候选人,整理了下我面试使用的题目,陆陆续续整理出来的题目很多,所以每次会抽一部分来问。答案会在后面的文章中逐渐发布出来。 基础题目Java线程的状态 进程和线程的区别,进程间如何通讯,线程间如何通讯 HashMap的数据结构是什么?如何实现的。和HashTable,ConcurrentHashMap的区别 Cookie和Session的区别 索引有什么用?如转载 2017-11-07 08:13:10 · 542 阅读 · 0 评论