暂时未有相关云产品技术能力~
暂无个人介绍
此篇算是对《voliatile,synchronized,cas》理论的一种实践
之前写了《熔断》,以及其中使用的《计数器算法》;本来是要接着再写不通过定时器清理计数环的计数器算法,看了下我司亿级网关的计数器,百行的代码,但却是满满bug。不得穿插一下并发的基础知识 处理并发,最基本的元件就这三样 1. synchronized 这个关键字不必讲,从开始多线程,它就进入你的视线 2. volatile 在jdk5之后大放异彩 3. cas 在J.U.C中大量使用,他与volatile组合是J.U.C的基石
《微服务-熔断机制》中提到了计数器,这篇详细学习一下计数器算法 之前的有次面试,碰到了计数器的的题目 Q:线上服务,设计一个拦截器,一个IP如果短时间内请求次数过多,就屏蔽 A:使用map,key为ip,值为次数与时间 Q:请求相当大,会直接冲垮内存,怎么办? A:使用redis,像redis cluster,绝对可以满足 Q: 写下伪代码 A:bbbbbbb 其实计数器在互联网开发中很常见,当时刚转互联网比较无知,面试得很烂。
由于微服务间通过RPC来进行数据交换,所以我们可以做一个假设:在IO型服务中,假设服务A依赖服务B和服务C,而B服务和C服务有可能继续依赖其他的服务,继续下去会使得调用链路过长,技术上称1->N扇出
最近收到了一份安全漏洞警告--用户账户恶意劫持漏洞,直指我们联登中的state参数存在严重问题 在之前的《常识二Oauth2.0介绍及安全防范》文章中已经说明了oauth2.0以及可能的csrf问题 看来知道和做到还是有些差距,通过这篇文章再来回顾一下此次漏洞问题
常识系列,作为一名互联网门外汉的科普系列 流程服务,乍一看,很高深的样子。其实是个很简单的东东! 看到流程,千万别想到workflow那种复杂的玩意。 不知道别的公司,别的部门有没有这种服务,这种服务是因实际痛点情况符合底层团队而生的一种服务。
最近又碰到gc问题,想起以前整理的一篇GC文章,在博客上很多人喜欢,特同步过来 这个GC跟JVM内容太多了,理论性东西多些,少年时还能记个八九成,好久没弄,都忘记了。这次权当整理温习,再看看《深入理解JVM虚拟机》,找些过去写的博客挖点东西过来!
在《常识五配置中心》文章中,少了一节关于zookeeper内容,现在补全 此篇也作为《从Paxos到zookeeper分布式一致性原理与实践》的读书笔记 这本书很早就出版了,现在才知道,惭愧。好书总是发现的晚,Better late than never! IT界日异月新,如果你还没有使用过ZK,那也可以跳过了,虽然现在大多数互联网架构都使用,但它也是个古老物件了。随着CoreOS和Kubernetes等项目在开源社区日益火热,etcd已是跃然而上,我司新一代配置中心架构也开始使用etcd代替zk 但功不唐捐,还是要努力抓住它的尾巴,回味一下错失的年华
快速可以说是互联网的最大特点了,唯快不破,快速响应,快速发布,快速部署,快速上线 但上线,毕竟还是有风险的,怎么能又快速响应,又能降低风险范围呢 前人,现人,后人们都在寻找着银弹 部署方式就进化了有很多次,蓝绿部署、滚动部署、灰度发布、金丝雀发布。。。 这些都是为了应对互联网的快速响应需求 游戏的发布现在还是比较粗暴的,对开发,运维也比较简单。 制定一个版本计划,开发,与运营沟通,确定版本内容,到了时间,所有游戏区全部关闭入口,停止服务器,发布,部署,重启,开放入口,一气呵成,快哉! 等等,理想很丰满,现实很骨感 在版本发布最后一天,开发人员在凌晨1、 2点时,还在开发,修复bug,好不容易打
常识系列,作为一名互联网门外汉的科普系列 本来这篇文章想谈一下zookeeper,现在已经家喻户晓了。结果看到江南白衣的文章 提到配置中心就跟你讲zk,etcd的,可能是个空想玩家,或者他家系统很小; 不由得冒了两滴冷汗,高人总是一针见血。 所以还是多关注一下互联网的架构,而不是技术的细枝末节 本篇涉及到的内容包括: 1. 游戏中配置中心的进化 2. 什么样的配置中心才叫好 3. 流行架构 4. zookeeper
常识系列,作为一名互联网门外汉的科普系列 堆外内存除了在像netty开源框架中,在平常项目中使用的比较少,在现前的项目中,QPS要求高的系统中,堆外内存作为其中一级缓存是相当有成效的。所以来学习一下,文中主要涉及到这三分部内容 1. 堆外内存是什么?与堆内内存的区别 2. 怎么分配,与GC的影响 3. 开源框架使用 这篇文章写到最后,发现还只是回答了开源框架OHC的Why not use ByteBuffer.allocateDirect()?
这篇其实本来也打算放在《常识》系列中的,介绍一下分布式日志追踪系统,这在互联网界理论,技术,产品已经很成熟,国内外各大厂都有自己成熟的产品。是个不错的互联网门外汉科普知识点 微服务,已经火了多年,也已经落地实施。对服务的监控需求顺理成章。监控系统的本质其实也就是分布式日志追踪系统。就归类到《微服务》系列中吧 本篇大体内容
用来解决并发事务时出现的问题,其使用TransactionDefinition中的静态变量来指定 1. ISOLATION_DEFAULT 使用后端数据库默认的隔离级别 2. ISOLATIONREADUNCOMMITTED 最低的隔离级别,允许读取尚未提交的数据变更,可能会导致脏读、幻读或不可重复读 3. ISOLATIONREADCOMMITTED 允许读取并发事务已经提交的数据,可以阻止脏读,但是幻读或不可重复读仍有可能发生
做什么都怕进入狗咬尾巴的怪圈,上次看hashmap源码还是2012年,这次出去面试时被问到了hashmap的问题,整体思路还是记得的,巴拉巴拉一堆。回来再看一下源码,温习一下 想要了解hashmap,就得先知道一下他的数据结构理论
这篇其实也要归纳到《常识》系列中,但这重点又是spring的介绍,故归档在spring系列中。 工作很多年,除了学生时代学过,事务还真没有用过。过去开发游戏时,完全不用事务;现在互联网开发,也没有使用事务的场景,不要见怪。
概念 假如把开发工作流程分为以下几个阶段: 编码 -> 构建 -> 集成 -> 测试 -> 交付 -> 部署
oAuth是Open Authorization的简写 OAuth(开放授权)是一个开放标准,允许用户让第三方应用访问该用户在某一网站上存储的私密的资源(如照片,视频,联系人列表),而无需将用户名和密码提供给第三方应用。
常识系列,作为一名互联网门外汉的科普系列
BeanPostProcessor是什么?在看bean初始化时,看到了很多的BeanPostProcessor,具体作用还真搞不清楚。 前人说这是spring的扩展点,遵循“开-闭原则”的一个扩展。可以进行自定义的实例化、初始化、依赖装配、依赖检查等流程,即可以覆盖默认的实例化,也可以增强初始化、依赖注入、依赖检查等流程 但我还是一脸蒙逼,到底是什么鬼? 网上找几个实例来个大体认知一下
从这个简单的代码衍生,使用AnnotationConfigApplicationContext看一下spring bean的初始化过程
做什么都怕进入狗咬尾巴的怪圈,上次看hashmap源码还是2012年,这次出去面试时被问到了hashmap的问题,整体思路还是记得的,巴拉巴拉一堆。回来再看一下源码,温习一下 想要了解hashmap,就得先知道一下他的数据结构理论
JIT主要关注三个点 1. JIT是什么 2. JIT的原理 3. JIT的意义
这个类,好早就有了,JDK1.2就出现了。有时也会用一用,但他的作用是什么,很难表达了,难以表达,不能形成文字,说明了解的深度不够。
motan第二篇,想写motan的rpc调用过程的,但项目中需要对motan进行扩展,所以本来就先记录下
motan weibo的RPC框架 这次在项目中引入了此框架。 在使用中学习。研读下源码。记录下使用学习过程。