暂时未有相关云产品技术能力~
暂无个人介绍
看过DDD的一些书,这次将自己的理解转化为代码。论语里说“学而不思则罔,思而不学则殆”,学会某种能力需要了解到新的知识并思考这些知识,比较好的方式便是动手实践。
关于状态机,以前写过[用Go实现一个状态机](https://mp.weixin.qq.com/s?__biz=MzUzNzAzMTc3MA==&mid=2247484850&idx=1&sn=5ba31ff066ddeeedab27f9ca9f1b9b58&scene=21#wechat_redirect),只是讲述了如何控制状态的流转,理论上不能算作完整的状态机。
OAuth是一个关于授权(authorization)的开放网络标准,在全世界得到广泛应用,目前的版本是2.0版。OAuth不是一个认证协议,这点不要搞混。
最近打算梳理消息引擎系统,以Kafka和RocketMQ为主进行学习。关于Kafka打算写两篇文章,一篇是基础知识,一篇是实践,打算用Kafka收集日志,并实现报警功能。Kafka版本经常更新,有的知识可能和最新版本不一致,这点需注意。
分布式事务分两大类,一类是XA类型的,一类是基于消息通知的事务方案。前些日子写了[分布式事务-2PC与TCC](https://mp.weixin.qq.com/s?__biz=MzUzNzAzMTc3MA==&mid=2247484814&idx=1&sn=e3467cbc3d7ae2149e8ad5c00ede9772&scene=21#wechat_redirect),这次聊一下Saga和基于消息的的事务方案。
Redis是应对高并发的常用工具,在[常用缓存技巧](https://mp.weixin.qq.com/s?__biz=MzUzNzAzMTc3MA==&mid=2247483715&idx=1&sn=d6a3223289443c0dd1cfd8ecafe2cbd9&scene=21#wechat_redirect)中讲过相关技巧。但有些业务场景,使用Redis会遇到问题,如电商里的秒杀、扣减库存等。
工作中,很多同学会用到状态机,例如对一个工单进行创建、编辑、审核,在执行新动作前,要检查能否从当前状态流转到下一个状态。对这种需求,我们怎么实现呢?
以前都是作为消息接收方,接收消息。记得当时做支付的时候,接收第三方支付公司的各种消息,如支付成功、支付失败、退款成功、退款失败。
随着微服务的发展,需要实现分布式事务的场景越来越多。分布式事务在实现上分为基于补偿的方案和基于消息通知方案两种类型。 基于补偿的方案有2PC、TCC模式、Saga模式、Seata AT模式,它们都可以看成是遵守XA协议或是XA协议的变种。本次只聊2PC和TCC,今后有时间再聊其它模式。
权限管理,一般指根据系统设置的安全规则或者安全策略,用户可以访问而且只能访问自己被授权的资源,不多不少。对权限做管理的系统,就是权限管理系统。
队列是一种特殊的线性表,特殊之处在于它只允许在表的前端(front)进行删除操作,而在表的后端(rear)进行插入操作,和栈一样,队列是一种操作受限制的线性表。进行插入操作的端称为队尾,进行删除操作的端称为队头。队列中没有元素时,称为空队列。
什么是分页复选设计呢?
以前写过一篇如何对接第三方支付的文章[如何高效对接第三方支付](https://mp.weixin.qq.com/s/NM34aevx3DBT1czcoFMJWw),因为对接的大多数是海外支付公司,这些公司有很多神奇的问题,往往会埋坑,所以开发之前,整理出问题列表,以便尽早发现和解除问题,保证按时上线。
剩下的几种本来打算能立即写完,没想到一下三个月过去了,很是尴尬。本次主要实现如下两种算法 - 令牌桶算法 - 漏斗算法
秒杀能够以极小的经费撬动巨大的流量,虽然会带来一定的口碑损失,但因为极具性价比,所以经常被运营同学使用。本文介绍如何设计一款能够支撑60W QPS的秒杀系统,希望能够帮助到大家。
分布式系统的设计目标一般包括如下几个方面 - 可用性:可用性是分布式系统的核心需求,其用于衡量一个分布式系统持续对外提供服务的能力。 - 可扩展性:增加机器后不会改变或极少改变系统行为,并且能获得近似线性的性能提升。 - 容错性:系统发生错误时,具有对错误进行规避以及从错误中恢复的能力。 - 性能:对外服务的响应延时和吞吐率要能满足用户的需求。
分布式系统的设计目标一般包括如下几个方面 - 可用性:可用性是分布式系统的核心需求,其用于衡量一个分布式系统持续对外提供服务的能力。 - 可扩展性:增加机器后不会改变或极少改变系统行为,并且能获得近似线性的性能提升。 - 容错性:系统发生错误时,具有对错误进行规避以及从错误中恢复的能力。 - 性能:对外服务的响应延时和吞吐率要能满足用户的需求。
微服务的水挺深的,准确的说,不仅深还特别广。微服务涉及的内容特别多,而且每一块都可以深入研究,成为这方面的专家。
微服务兴起已经多年了,这几年已到大发展阶段。公司内部做了很多和微服务相关的事情,自己也看了一些微服务相关的内容。现在再来认识”微服务“三个字,终于有点懂了的感觉。
在实际业务中,经常会碰到突发流量的情况。如果公司基础架构做的不好,服务无法自动扩容缩容,在突发高流量情况下,服务会因为压力过大而崩溃。更恐怖的是,服务崩溃如同多米诺骨牌,一个服务出问题,可能影响到整个公司所有组的业务。
在项目中,大家经常会遇到处理高并发的情况,缓存是应对高并发的有效手段之一。这篇文章简单介绍一下常用的缓存手段。
电商购物流程中核心的一环是用户支付。目前我们已经服务30个国家和地区,不同国家往往需要对接不同的第三方支付公司,所以最近两年,研发组对接了大量的第三方支付公司,积累了一定的经验。
好久没有写网络相关的文章了。正好这两天和同事聊长连接,所以把这方面的内容进行梳理。
最近发现部分同学虽然知道HTTP错误码,但对产生的具体原因并不清楚,所以我打算对比较常见的错误码进行模拟,帮助大家理解。
本文讲述如何将自己的服务支持HTTP2。
现在网站使用HTTPS是规范操作之一,前些日子买了腾讯云服务,同时申请了域名http://www.asap2me.top/,目前该域名只支持HTTP,想升级为HTTPS。
HTTP协议通信过程中使用未经加密的明文,安全性无法得到保证。比如在Web页面中输入信用卡号,如果这条通信线路遭到窃听,那么信用卡号就暴露了。
本次和大家聊一下TCP性能优化。
CDN主要是让用户访问资源的时候,能从离用户距离很近的CDN节点进行获取,不必到真正提供服务的机器上获取。所以CDN可以
历经两个月的时间,将算法知识重新梳理完成,整个过程挺累的,每天只能晚上或者周六周日梳理一部分,虽然占用了大量的休息时间,不过整个过程很充实,而且也重新学到了不少东西。
回溯法是深度优先策略遍历问题的解空间树。分支限界法按**广度优先策略**遍历问题的解空间树,在遍历过程中对已经处理的每一个节点根据衔接函数估算目标函数的可能取值,从中选取使目标函数取得极值(极大或极小)的节点优先进行广度优先搜索,从而不断调整搜索方向,尽快找到问题的解。
回溯法就是一种有组织的系统化搜索技术,可以看作是蛮力法穷举搜索的改进。
贪心法是把一个复杂问题分解为一系列较为简单的局部最优选择,每一步选择都是对当前解的一个扩展,直到获得问题的完整解。贪心法的典型应用是求解最优化问题,而且对许多问题都能得到整体最优解,即使不能得到整体最优解,通常也是最优解的很好近似。
动态规划是在20世纪50年代由美国数学家贝尔曼为研究最优控制问题而提出的,当该方法在应用数学中的价值被大家认同以后,在计算机学界,动态规划法成为一种通用的算法设计技术用来求解多阶段决策最优化问题。
分治法是把一个大问题划分为若干个子问题,分别求解各个子问题,然后再把子问题的解进行合并得到原问题的解。 减治法同样是把一个大问题划分为若干个子问题,但是这些子问题不需要分别求解,只需求解其中的一个子问题,因而也无需对子问题的解进行合并。
分治法将一个难以直接解决的大问题划分成一些规模较小的子问题,分别求解各个子问题,再合并子问题的解得到原问题的解。
蛮力法的主要思想就是用最简单的思路解决问题,一般性能不好,但仍然很重要。
根据王红梅编著的《算法设计与分析》,读取每一章的内容,然后从乐扣上找对应的算法题,包含简单-中等-困难三种程度。尽量每两周能够完成一章。遇到一种类型的问题时,先自己想想解决方案,然后再看标准答案。
中介者模式是设计模式系列中最后一个模式。这个模式我从未用过,主要原因是没碰到过合适的场景。如果大家有适合使用中介者模式的场景,中介者模式能帮大家更好的维护系统。
命令模式很多同学可能不会用到,但这个模式还是蛮有意思的。命令模式能够将操作和数据打包成对象,便于系统对命令进行管理、维护。
访问者模式理解比较困难。可以认为对象开了一扇门,用来接收访问者,然后访问者便可在对象内部操作对象。简单来说,对象对访问者进行了授权。这样做能够实现对象和操作的解耦,职责更加单一。对象只管理自身,操作功能安置在访问者中。
迭代器模式从来没有写过,第一次接触迭代器,还是好多年前学C++的STL的时候。当时觉得用迭代器太麻烦了,后来用习惯了觉得真香。
状态模式使用的相对较少,主要是因为会引入大量的状态类,导致代码比较难维护。但是合适的场景使用状态模式,可以把复杂的判断逻辑简化。
职责链将处理模块串联成链,请求沿着链条被处理,提供了很好的扩展性,而且能够去掉if-else。
策略模式可能是很多同学学习到的第一种模式。这个模式确实适合作为开篇模式来讲,主要原因在于该模式简单、纯粹、没有太多技巧,但是很好的表达出了设计模式的理念,让读者能够直观的感受到设计模式带来的好处。
终于写完了创建型和结构型设计模式(共12个),现在开始写行为型设计模式(共11个)。观察者模式的应用场景非常广泛,小到代码层面的解耦,大到架构层面的系统解耦,再或者一些产品的设计思路,都有这种模式的影子。
前面三篇文章讲了代理模式、桥接模式、装饰器模式,这次讲一下适配器模式。 适配器模式比较简单,也比较容易理解。适配器模式可以看作一种“补偿模式”,用来补救设计上的缺陷。应用这种模式算是“无奈之举”。
装饰器模式主要解决继承关系过于复杂的问题,通过组合来替代继承。它主要的作用是给原始类添加增强功能。 装饰器类和原始类继承同一个父类,这么看感觉和代理模式一样。但其实两者作用不同,装饰器模式主要用于增加功能,代理模式主要用于附加跟原始类无关的功能。
桥接模式并不常用,而且桥接模式的概念比较抽象。桥接模式一般用于有多种分类的情况,如果实现系统可能有多角度分类,每一种分类都有可能变化,那么就把这种多角度分离出来让他们独立变化,减少他们之间的耦合。
从本篇文章开始讲解结构型模式,结构型模式主要总结了一些类或对象组合在一起的经典结构,这些经典的结构可以解决特定应用场景的问题。