暂无个人介绍
服务容灾的解决方案就是冗余。多几个备份来切换。常用的有N+1容灾和两地三中心。N和中心实际上都是机房的意思。所谓中心就是数据中心。N是数据中心的电力配置部分。电力配置有市电和备用发动机供电,但是一般互联网公司是不支持备用发动机供电的。所以一般一个机房就是一个N。
1,目标很重要 2,专注很有力量 3,比起「有所为」、「有所不为」更为关键
一致性分为强一致性和弱一致性。 强一致性的协议和手段主要有:二阶段提交(2PC)、三阶段提交(3PC)、TCC(Try-Confirm-Cancel)补偿型。这里面经常有人把两阶段提交和TCC补偿型混淆。二阶段提交实际上业务逻辑是在提交之前做的,两阶段只是事务控制的两个阶段。而TCC是将业务逻辑分为try、confirm和cancel三个阶段。举个例子:比如一个人要预售苹果,有两种销售策略。一种让用户先付钱,根据用户需求量准备足够的苹果。另一种是让用户先付钱同时声明到时候先到先得,没抢到的就退款。第一种就是二阶段提交,第二种就是TCC。弱一致性在分布式系统中常用的是一种特例:最终一致性。
Redis很好用,相比memcached多了很多数据结构,支持持久化。但是在很长一段时间里,原生是不支持分布式的。后来就出现了很多redis集群类产品,Tair是其中胜出的优秀作品之一。 所以Tair的特性都是一些集群的特性,比如:容错、解决单点故障、跨机房管理、多集群管理、支持副本等。总而言之,是redis的高可用版本。
Elasticsearch实战-磁盘IO被打满
在实际开发中,数据的处理有五种:获取、传输、存储、分析、转换。每种各对应一些常用的技术。
这是排查问题的最常用的方法,需要预估自己每日日志量和需要存储的日志时间。申请磁盘空间时一般会留35%的冗余以备突发流量。
背景前段时间开发一个接口,因为调用我接口的同事脾气特别好,我也就不客气,我就直接把源代码发给他当接口定义了。 没想到同事看到我的代码问:要么 get a,b,c 要么 post [a,b,c]。这么写可以自动解析?他们一直都是自己转换成list。
代码荣辱观-以运用风格为荣,以随意编码为耻
引子 平时我是个反应非常慢的人。有多慢呢?大概是两年前有次团队内部开会时,我听到同学说平时代码中用不到设计模式,我当时没有回答。两年后我终于反应过来了:“Are you kidding me?我每天都在用!”
kubernetes在容器编排大战中由于应用的可移植性以及支持混合云/多云部署方式上的灵活性。加上开放可扩展的理念,使得周边社区非常活跃。从既有调研结果看,kubernetes已成为容器编排领域的标准。但是它并不成熟,很多方面都大有可为,下面就是列举了一些方面:
稳定性三十六计-超时处理
为什么要做历史记录 历史记录是大数据的最重要数据源。通过历史记录可以进行事件追溯、未来预判和推荐。举个例子: 静儿在网上搜索了“稳定性三十六计”这个词,找到自己想要的内容了。然后去做别的事情,再打开浏览器的时候,发现旁边的小弹出框里推荐我《稳定性宝典》这本书。 这个推荐效果很多种算法都能实现,比如最近比较火的“协同过滤推荐算法(Collaborative Filtering Recommendation)”。啥是协同过滤推荐算法呢?协同过滤推荐算法简而言之,就是找到相同兴趣的群体,将这个群体中感兴趣的其他信息推荐给用户。 实施的时候可以先建立一个大表,X轴是所有的推荐内容,Y轴是所有的用户。
为什么要幂等 世界上最遥远的距离是我终于鼓起勇气,对着马路对面的你大喊:“你愿意娶我吗?”我看到你面带灿烂的笑容,正回答的时候……一辆大卡车驶过,你的回答我没有听见。 因各种不可抗因素产生的没有收到响应,一个简单有效的方法就是重试。被重试的接口必须是幂等的。 幂等性是分布式系统设计中的一个重要概念,对超时处理、系统恢复等具有重要意义。
「领域驱动设计」之于微服务,好比麦当劳之于汉堡(个人更喜欢肯德基,汉堡要大些,麦当劳的汉堡,想吃顿饱饭,请先给我上6个😂)。但是TDD测试驱动、MDD模型驱动好像也很火啊,到底什么在驱动?
JAVA SPI(Service Provider Interface)原理、设计及源码解析(其一)
测试了一下编解码的执行效果
稳定性「三十六计」实战和背后的逻辑
稳定性「三十六计」- 无状态化
Kubernetes的DaemonSet(下篇)
使用Elasticsearch的动态索引和索引优化
Kubernetes的DaemonSet(上篇)
Elasticsearch的基本概念和指标
Kubernetes的污点和容忍(下篇)
Kubernetes的污点和容忍(上篇)
程序员工作中的三个锦囊
实战并发-使用分布式缓存和有限状态机
一个请求过来都经过了什么?(Thrift版)
业务开发转基础开发,这三种「高可用」架构你会么?
程序常用的设计技巧
美团分布式服务通信框架及服务治理系统OCTO
到底多大才算高并发?
架构师是互联网行业高薪又紧俏的资源。成为架构师最基本的是设计能力。设计与设计的区别主要体现在两方面: 1,深度:要解决哪些问题?这个问题背后的根本问题是什么?还有什么问题没有发现?对应的能力是发现和解决问题的能力。 2,体系:要解决的问题的属于哪一类的问题?这类问题能否进一步抽象,让系统解决更大的问题?对应的抽象归纳和体系化思维的能力。
静儿最近反思很多事情,不仅是当时做错了。错误定式形成的思维习惯对自己的影响比事情本身要大的多。经常看到周围的同事,非常的羡慕。他们都很聪明、有自己的方法。就算有些同事工作经验相对少一些,但是就像在废墟上创建一个辉煌的城市要比在一个已有城市上建设要简单的多一样,我未来要走的路要更长。今天分享出来,希望大家能少走一些弯路。
项目中必须对应的隐性需求-安全漏洞修复
学会用数据说话-分布式锁究竟可以多少并发?
实践高可用
一款低延迟的分布式数据库同步系统--databus
《静儿的服务治理私房菜》服务治理概述
架构师之路--搜索业务和技术介绍及容错机制
架构师之路--应用架构的选型和dubbo
架构师之路--谈架构师的基本素养和[干货]日志处理
架构师之路--从业务角度谈缓存的选型
读数据除了直接依赖DB的内部操作之外,就是直接通过http请求的RPC调用。因为调用这个接口的业务方非常多,他们用的语言和技术非常杂,http有更好的通用性和便于运营人员等不懂技术的人排查问题,只能内网访问,也很安全。这是部门并发量最大的服务。单台机器QPS一般在2k多,低谷时在1k多,高峰时在3k多。线上11台接口服务器同时工作。但是读数据为了提高并发量,将全量的视频和专辑数据存在了memcached缓存里。所以一旦其他业务方更新了数据会直接发送MQ消息给读数据服务,读数据服务更新了缓存后要给业务方回复消息。
下面介绍一些Lucene使用基本规则和算法。这些规则和算法的选择,都和Lucene和支持TB级的倒排索引有关。
用线上升级平台代码练手,学习JAVA。飞哥建议我们自己从头再搭建一套,提高会大。我自己作为一个JAVA出身的人,用了几天时间学会PHP的经验来看。最好,先在原来代码基础上改些东西。熟悉了基本语法之后再来重新搭建一套。如果本来就是一头雾水,再加上全身心投入的时间不够充裕的话,可能会欲速而不达。
看了一下代码,同时在线上做了观察压测。个人总结这个接口问题在于太过于依赖缓存,根本不会走DB。依赖缓存造成了依赖缓存的数据结构。首先要从缓存中取出一堆数据。而且要走两次,一次取正片的信息,一次取专辑内所有视频的信息。取出来的信息在CPU里计算筛选,排序。本身缓存取数据就比较快,再加上计算量大。其实我们并发量最大的api接口们都是采用这个模式设计的。调用的多了,我觉得我真是压测的狠的话,会造成CPU密集。其实现在的缓存之类的都可以持久化了,完全可以当数据库用。但是关系型数据作为一个长久的经典还有一个很重要的原因:保持一个IO和CPU使用的平衡。
我面试人家的时候特别喜欢问一个问题:”请描述一下一个请求过来到响应完成都做了什么,越详细越好。” 对于一个高手来说,他只要回答好了这一个问题,技术面试就通过了。所以如果我要去面试,我就把这个问题的答案压缩到40分钟到1个小时。因为一般的技术面试都是这个时间段哒,虽然我其实很想讲上两天。哎,一看我们部门就是做业务的。 为了让人家听懂,我一般会设置一个业务场景。比如说:现在用户要开始上传一个视频。那么业务上要经过用户打开浏览器页面,用户点击[选择视频文件]按钮,JS端调用系统本地文件选择器,JS端将视频信息写入到浏览器页面,用户点击[开始上传],此时开始发送请求。
前几天和同事聊天,同事说: “业务的服务(相对于我们基础架构这边的底层技术)在技术上就需要解决三个问题:分布式、通信和存储。” 我回忆之前做业务的时光,觉得确实,再加上一个“服务治理”就差不多了。想想“服务设计要解决的问题”这个话题可以把之前静儿写的很多文章做一个归纳概括。今天做一个总结。
上周静儿用一天的时间写了一个日志切面,大家都非常支持配合,内部各个模块都使用起来。 从技术上来说就是一个aspectj,没有什么难点。关键是做好之后让很多模块都一起使用起来,形成了一个规范。规范是一个很神奇的东西。 比如因特网本身就是一套规范而已。所谓的带宽是连电压都规定好了的大家必须遵守的东西。比如神奇的http,也就是一套约定的规范。 那简明日志规范到底有什么意义呢?回到之前静儿写的文章:美团点评智能支付核心交易系统的可用性实践。