暂无个人介绍
阿里云上有个阿里巴巴编码规范认证,我估算一下时间成本很低,多个认证也没什么坏处,就花了1分钱报了个名。这个认证报名后就可以下载链接下的编码规范,然后参加个考试应该就OK了。 共48页的规范实际上每读一遍都是要花一些时间的,因为每读一遍就会发现上面有些东西我不信。我需要去证明。过去证明过的因为JDK版本升级迭代有可能需要继续证明。下面是其中的一些证明过程。
MySQL常见6个考题在实际工作中的运用
Java&Spring过时的经典语录
服务容灾的解决方案就是冗余。多几个备份来切换。常用的有N+1容灾和两地三中心。N和中心实际上都是机房的意思。所谓中心就是数据中心。N是数据中心的电力配置部分。电力配置有市电和备用发动机供电,但是一般互联网公司是不支持备用发动机供电的。所以一般一个机房就是一个N。
1,目标很重要 2,专注很有力量 3,比起「有所为」、「有所不为」更为关键
很早之前听同事说:“要开会了。我都知道领导要问什么,就那几板斧。”其实领导之所以为领导,人家问的问题确实很合情合理,甚至可以说一针见血。而之所以能问出来这些合理的问题,就是因为头脑中有自己的思考框架。比如要做一件事情,一个思考框架就是: 1,我们现在是什么样的? 2,我们要做成什么样(解决什么问题、有什么收益)? 3,怎么才能达成(解决路径)?
一致性分为强一致性和弱一致性。 强一致性的协议和手段主要有:二阶段提交(2PC)、三阶段提交(3PC)、TCC(Try-Confirm-Cancel)补偿型。这里面经常有人把两阶段提交和TCC补偿型混淆。二阶段提交实际上业务逻辑是在提交之前做的,两阶段只是事务控制的两个阶段。而TCC是将业务逻辑分为try、confirm和cancel三个阶段。举个例子:比如一个人要预售苹果,有两种销售策略。一种让用户先付钱,根据用户需求量准备足够的苹果。另一种是让用户先付钱同时声明到时候先到先得,没抢到的就退款。第一种就是二阶段提交,第二种就是TCC。弱一致性在分布式系统中常用的是一种特例:最终一致性。
Redis很好用,相比memcached多了很多数据结构,支持持久化。但是在很长一段时间里,原生是不支持分布式的。后来就出现了很多redis集群类产品,Tair是其中胜出的优秀作品之一。 所以Tair的特性都是一些集群的特性,比如:容错、解决单点故障、跨机房管理、多集群管理、支持副本等。总而言之,是redis的高可用版本。
Topic 每条发布到 Kafka 集群的消息都有一个类别,这个类别被称为 Topic。(物理上不同 Topic 的消息分开存储,逻辑上一个 Topic 的消息虽然保存于一个或多个 broker 上但用户只需指定消息的 Topic 即可生产或消费数据而不必关心数据存于何处)
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)原理、设计及源码解析(其一)
测试了一下编解码的执行效果
稳定性「三十六计」实战和背后的逻辑
稳定性「三十六计」- 无状态化
设置默认的超时和重试是一个基础设施的基本素养
背景 《SRE Google运维解密》里提到SRE自动化系统的一个bug导致几乎所有的数据中心机器被成功下线并进行硬盘擦除。当然这本书出版之后又业界也进行了很多的演进。在我们团队现在很难发生这样的事情。因为团队内人人要遵循的一个设计原则是:原则上禁止批量操作。如需批量,需要有审核流程。批量设置上限。 这个原则在我以后会发布的系列文章《架构设计「三大纪律八项注意」》中也会介绍一些。今天先从另一个角度系统的看这个问题。
引入服务网格
Kubernetes的DaemonSet(下篇)
使用Elasticsearch的动态索引和索引优化
Kubernetes的DaemonSet(上篇)
Elasticsearch的基本概念和指标
Kubernetes的污点和容忍(下篇)
Kubernetes的污点和容忍(上篇)
程序员工作中的三个锦囊
实战并发-使用分布式缓存和有限状态机
一个请求过来都经过了什么?(Thrift版)
业务开发转基础开发,这三种「高可用」架构你会么?
程序常用的设计技巧
美团分布式服务通信框架及服务治理系统OCTO
到底多大才算高并发?
架构师是互联网行业高薪又紧俏的资源。成为架构师最基本的是设计能力。设计与设计的区别主要体现在两方面: 1,深度:要解决哪些问题?这个问题背后的根本问题是什么?还有什么问题没有发现?对应的能力是发现和解决问题的能力。 2,体系:要解决的问题的属于哪一类的问题?这类问题能否进一步抽象,让系统解决更大的问题?对应的抽象归纳和体系化思维的能力。
静儿最近反思很多事情,不仅是当时做错了。错误定式形成的思维习惯对自己的影响比事情本身要大的多。经常看到周围的同事,非常的羡慕。他们都很聪明、有自己的方法。就算有些同事工作经验相对少一些,但是就像在废墟上创建一个辉煌的城市要比在一个已有城市上建设要简单的多一样,我未来要走的路要更长。今天分享出来,希望大家能少走一些弯路。
项目中必须对应的隐性需求-安全漏洞修复
学会用数据说话-分布式锁究竟可以多少并发?
经过了几天的熟悉环境,小鱼开始让飞鸟尝试负责解决一些问题。分配的第一个问题现象是这样的: 接口有偶尔的超时现象。平时的时候接口可以在2s响应调用的上游。但是偶尔会有几次,超时特别严重,有时候20s、30s才返回。但是上游的超时时间是10s。所以这时候上游是拿不到结果的。对上游来说这次请求失败了。 飞鸟通过排查,找到了一些线索,就抱着电脑去找小鱼。
实践高可用
一款低延迟的分布式数据库同步系统--databus
《静儿的服务治理私房菜》网络模型的分类和职业规划思考
《静儿的服务治理私房菜》服务治理和架构