嘻哈熊的专栏

李平前言在前一篇随笔《大型网站系统架构的演化》中，介绍了大型网站的演化过程，期间穿插了一些技术和手段，我们可以从中看出一个大型网站的轮廓，但想要掌握设计开发维护大型网站的技术，需要我们一步一步去研究实践。所以我打算写一个系列，从理论到实践讲述大型网站的点滴，这也是一个共同学习的过程，希望自己能坚持下去。系列大概会分为两部分，理论和实践，理论部分尽量通俗易懂，也要讲一些细节。实践部分会抽取一些技术做实践，将方法、解决问题过程分享出来。本文将讲述大型网站中一个重要的要素，性能。什么是性能。...

在我们编程中常见幂等select 查询天然幂等delete 删除也是幂等, 删除同一个多次效果一样update 直接更新某个值的, 幂等update 更新累加操作的, 非幂等insert 非幂等操作, 每次新增一条由于重复点击或者网络重发 eg:点击提交按钮两次;点击刷新按钮;使用浏览器后退按钮重复之前的操作，导致重复提交表单;使用浏览器历史记录重复提交表单;浏览器重复的 HTTP 请;nginx 重发等情况;分布式 RPC 的 try 重发等;1) 前端 js 提交禁止按钮可以用一些 js 组件2) 使用

前后端分离模式下，所有的交互场景都变成了数据，传统业务系统中的权限控制方案在前端已经不再适用，因此引发了我对权限的重新思考与设计。对于非前后端分离模式下的权限思考，看这里：通用数据权限的思考与设计在理解权限控制之前，需要明白两个概念：资源和权限。什么是资源，对于一个系统来说，系统内部的所有信息都可以理解为这个系统的资源。页面是资源、数据是资源、按钮是资源、图片是资源、甚至页面上一条分割线也可理解为是这个系统的资源。而权限就是访问某个资源所需要的标识。无论系统的权限如何设计，在用户登录时，都可以计算得出用户所

1、解耦2、异步3、削峰使用了消息队列会有什么缺点?消息队列如何选型?如何保证消息队列是高可用的？如何保证消息不被重复消费？如何保证消费的可靠性传输?RabbitMQkafka如何保证消息的顺序性？总结一个用消息队列的人，不知道为啥用，有点尴尬。没有复习这点，很容易被问蒙，然后就开始胡扯了。**回答：**这个问题, 咱只答三个最主要的应用场景，不可否认还有其他的，但是只答三个主要的，即以下六个字:解耦、异步、削峰传统模式:传统模式的缺点：系统间耦合性太强，如上图所示，系统 A 在代码中直接调用系统 B 和系

前阵子有网友询问，如何优化网站？这个问题真的很大，跟他简单的聊了一下，随便说了几点，觉得有必要整理一篇文章出来，正好前阵子在做爬虫博客，于是把大体思路分享出来，与大家互通有无，共同进步。系统开始是这样子的，一个 Tomcat 拖着一个 MySql 服务，跑在一个 2C 4G 的 Linux 服务器上，所有的请求都走 Tomcat，所有的查询都走 MySql，看起来像一句废话？资源是有限的，那么如何有效的利用资源，提升服务性能？Tomcat 号称能抗住数十万并发访问，但是这事也得分场景，还得有足够牛逼的机器。

点击上方蓝色字关注我们~Dubbo 服务化，在当前互联网后端开发中，大部分都使用了 Dubbo。截止目前 github dubbo 上，star 也将近 3 万，使用 dubbo 的公司数量也很可观，Dubbo 确实也是一个比较不错的服务化框架。下面整理比较不错的 Dubbo 服务化最佳实践，希望可以帮助我们少掉进一些坑，更好的使用 Dubbo。1分包：公共 API建议将服务接口，服务模型，服务异常等均放在 API 包中，因为服务模型及异常也是 API 的一部分，同时，这样做也符合分包原则：重用发布等价原则

一、数据库瓶颈1、IO 瓶颈2、CPU 瓶颈二、分库分表三、分库分表工具四、分库分表步骤五、分库分表问题六、分库分表总结七、分库分表示例不管是 IO 瓶颈，还是 CPU 瓶颈，最终都会导致数据库的活跃连接数增加，进而逼近甚至达到数据库可承载活跃连接数的阈值。在业务 Service 来看就是，可用数据库连接少甚至无连接可用。接下来就可以想象了吧（并发量、吞吐量、崩溃）。第一种：磁盘读 IO 瓶颈，热点数据太多，数据库缓存放不下，每次查询时会产生大量的 IO，降低查询速度 -> 分库和垂直分表。第二种：网络 I

来源：http://1t.click/ane7# 前言目前在公司负责权限这块，所以对权限这块的设计比较熟悉，公司采用微服务架构，权限系统自然就独立出来了，其他业务系统包括商品中心，订单中心，用户中心，仓库系统，小程序，多个 APP 等十几个系统和终端。# 权限模型迄今为止最为普及的权限设计模型是 RBAC 模型，基于角色的访问控制（Role-Based Access Control)。1、 RBAC0 模型RBAC0 模型如下:这是权限最基础也是最核心的模型，它包括用户 / 角色 / 权.

原文地址 mp.weixin.qq.com作者：小灰需要规划出怎样的路线呢？举个例子：有一个快递员，要分别给三家顾客送快递，他自己到达每个顾客家的路程各不相同，每个顾客之间的路程也各不相同。那么，想要把快递依次送达这三家，并最终回到起点，哪一条路线所走的总距离是最短的呢？旅行商问题和小灰所遇到的问题类似，旅行商问题所描述的是这样一个场景：有一个商品推销员，要去若干个城市推销商品。该推销员从一个城市出发，需要经过所有城市后，回到出发地。每个城市之间都有道路连通，且距.

原文地址 mp.weixin.qq.com在传统的单服务架构中，一般来说，只有一个服务器，那么不存在 Session 共享问题，但是在分布式 / 集群项目中，Session 共享则是一个必须面对的问题，先看一个简单的架构图：在这样的架构中，会出现一些单服务中不存在的问题，例如客户端发起一个请求，这个请求到达 Nginx 上之后，被 Nginx 转发到 Tomcat A 上，然后在 Tomcat A 上往 session 中保存了一份数据，下次又来一个请求，这个请求被转发到 Tomcat B 上，此.

**作者：**闪客 sunhttps://www.cnblogs.com/flashsun一直不知道性能优化都要做些什么，从哪方面思考，直到最近接手了一个公司的小项目，可谓麻雀虽小五脏俱全。让我这个编程小白学到了很多性能优化的知识，或者说一些思考方式。真的感受到任何一点效率的损失放大一定倍数时，将会是天文数字。最初我的程序计算下来需要跑 2 个月才能跑完，经过 2 周不断地调整架构和细节，将性能提升到了 4 小时完成。整体性能提升了 360 倍很多心得体会，希望和大家分享，也希望多多批评指正，共同进

原文地址 mp.weixin.qq.com本文翻译自英文，原文标题是 Cacheing Strategies and How to Choose the Right One，同事推荐看的，觉得总结的不错，鉴于很多同学都懒得看英文的，所以皮皮就用蹩脚的水平试着翻译一波，如何觉得还凑合，记得点个 “在看”，-。缓存是提高系统性能的最简单方法之一。相对而言，数据库（or NoSQL 数据库）的速度比较慢，而速度却往往又是制胜的关键。如果使用得当，缓存可以减少相应时间、减少数据库负载以及节省成本。本文罗.

本文由 简悦 SimpRead 转码， 原文地址 mp.weixin.qq.com点击上方 “刘望舒”，马上关注，早上 8:42 推送真爱，请置顶或星标作者: 谭妥 | 来源：公众号: 谭妥https://blog.youkuaiyun.com/weixin_37734988/article/details/92796055前言这是我自己做的一个仿滴滴打车的 Android 出行项目，主要针对滴滴等出行平台一直饱受质疑的 “人车不符” 问题，以及当前越发火热的国际化和出海.

本文由 简悦 SimpRead 转码， 原文地址 mp.weixin.qq.com点击上方 “方志朋”，选择 “设为星标”做积极的人，而不是积极废人今天这篇文章我们来聊聊在分布式环境下的一个神兵利器——分布式锁！在看这篇文章的时候，默认大家对锁已经了解了，如果不了解的朋友可以去翻翻公号前面的文章，有很多篇详细介绍了锁的一些知识。写这篇文章的主要原因是之前星球中有朋友说面试中被问的频率有点高，虽然知道分布式锁是什么，但是还是不能很好的说出来，这篇文章就是帮助大家好好梳理一下分布式锁的原理，希望对.

一个大型网站应用一般都是从最初小规模网站甚至是单机应用发展而来的，为了让系统能够支持足够大的业务量，从前端到后端也采用了各种各样技术，前端静态资源压缩整合、使用 CDN、分布式 SOA 架构、缓存、数据库加索引、读写分离等等。这些技术是高并发系统所必须的，但是今天先不细说，而先谈谈在这些架构既定的情况下，一些高并发业务 / 接口实现时应该注意的原则，以及通过工作中一个 6 万 QPS 的秒杀活动，来介绍一下秒杀业务的特点.

本文由 简悦 SimpRead 转码， 原文地址 mp.weixin.qq.com第1则网站关注点之数据库 -首先是数据库, 这是大多数应用所面临的首个 SPOF。尤其是 Web2.0 的应用，数据库的响应是首先要解决的。一般来说 MySQL 是最常用的，可能最初是一个 MySQL 主机，当数据增加到 100 万以上，那么，MySQL 的效能急剧下降。常用的优化措施是 M-S（主 - 从）方式进行同步复制，将查询和操作和分别在不同的服务器上进行操作。我推荐的是 M-M-Slaves 方.

本文由 简悦 SimpRead 转码， 原文地址 mp.weixin.qq.com点击上方 “芋道源码”，选择 “设为星标”做积极的人，而不是积极废人！源码精品专栏中文详细注释的开源项目RPC 框架 Dubbo 源码解析网络应用框架 Netty 源码解析消息中间件 RocketMQ 源码解析数据库中间件 Sharding-JDBC 和 MyCAT 源码解析作业调度中间件 Elastic-Job 源码解析分布式事务中间件 TCC-Transaction 源.

软件架构演进 软件架构的发展经历了从单体结构、垂直架构、SOA 架构到微服务架构的过程，博客里写到了这四种架它们的特点以及优缺点分析，个人学习之用，仅供参考！1.1.1 单体架构 特点：1、所有的功能集成在一个项目工程中。2、所有的功能打一个 war 包部署到服务器。3、应用与数据库分开部署。4、通过部署

原文地址 mp.weixin.qq.com摘要：　　本文首先以一个经典的分布式缓存的应用场景为铺垫，在了解了这个应用场景之后，生动而又不失风趣地介绍了一致性哈希算法，同时也明确给出了一致性哈希算法的优点、存在的问题及其解决办法。一. 引子在了解一致性哈希算法之前，最好先了解一下缓存中的一个应用场景，了解了这个应用场景之后，再来理解一致性哈希算法，就容易多了，也更能体现出一致性哈希算法的优点，那么，我们先来描述一下这个经典的分布式缓存的应用场景。1、场景描述假设，我们有三台缓存服务器，用于缓存图.

来源：http://t.cn/EoMKcLJ单一职责原则开闭原则里氏替换原则依赖倒置原则接口隔离原则迪米特原则总结这是设计模式系列开篇的第一篇文章。也是我学习设计模式过程中的总结。这篇文章主要讲的是面向对象设计中，我们应该遵循的六大原则。只有掌握了这些原则，我们才能更好的理解设计模式。 我们接下来要介绍以下 6 个内容。单一职责原则——SRP开闭原则——OCP里式替换原则——LSP依赖倒置原则——DIP接口隔离原则——IS.

来源：http://t.cn/Eogt0kw需求介绍原理解释网页端 + 服务器手机端 + 服务器登录成功需求介绍首先，介绍下什么是扫码登录。现在，大部分同学手机上都装有 qq 和淘宝，天猫等这一类的软件。而开发这些 app 的企业，都有他们相对应的网站。为了让用户在使用他们的网站时，登录更加方便和安全。这些企业提供了， 使用手机，扫一扫，就可以登录的服务。网页登录时的效果如下：imgimg有很多小伙伴可能会感到很神奇，网页上只是显示了个二维码，它怎么就知道是.

作者：xybabycnblogs.com/xybaby/p/9055734.html作为一个程序员，性能优化是常有的事情，不管是桌面应用还是 web 应用，不管是前端还是后端，不管是单点应用还是分布式系统。本文从以下几个方面来思考这个问题：性能优化的一般性原则，性能优化的层次，性能优化的通用方法。本文不限于任何语言、框架，不过可能会用 Python 语言来举例。不过囿于个人经验，可能更多的是从 Linux 服务端的角度来思考这些问题。一般性原则依据数据而不是凭空猜测这是性能优化的第一原则，当.

来源：http://t.cn/RVDWcfe一、资料文档二、开发语言三、支持的协议四、消息存储五、消息事务六、负载均衡七、集群方式八、管理界面九、可用性十、消息重复十一、吞吐量 TPS十二、订阅形式和消息分发十三、顺序消息十四、消息确认十五、消息回溯十六、消息重试十七、并发度本文将从，Kafka、RabbitMQ、ZeroMQ、RocketMQ、ActiveMQ 17 个方面综合对比作为消息队.

来源：http://t.cn/EbMSlGi数据获取图的二维数组展现Dijkstra代码的实现优化尾巴现在的公共交通越来越方便，很多城市都有地铁，日常使用的地图 App 都提供了地铁线路换乘方案的功能，只要输入起点和重点，App 就能给出你换乘的方案，可是这个功能背后的算法又是怎么样的呢。这篇文章将会告诉你。说到最短路径算法不外乎就是那么几种，广度优先深度优先 Dijkstra 之类的，这篇博客将会讲述 Dijkstra 算法，其他的最短路径算法我的其他文章.

一、wap 站①、支付宝接入1、开发前准备：申请一个通过实名认证的企业支付宝账号，并申请开通手机 WAP 支付功能。2、流程参数准备：企业支付宝账号的 PID(也叫 ParnerID) 和 KEY，如果使用 RSA 签名而不是 MD5 的话，还要把 RSA 私钥准备好支付时用户看到的东西：商品名称 (subject)、支付总额（total_fee）、购买数量（通常都是 1 吧）交易后的跳转地址，交易成功后用户可以手工点击，或页面延迟自动跳转到这个地址 (return_url)

原文地址 微信公众号如下图所示是华为手机应用商店首页截图，我们看到有几个模块：精品应用，精品新游，还有截图中没有展示出来的大家都在用模块等。无论这些模块的 APP 是以多复杂的算法推荐的，其最终展示给用户看的就是 30 个 APP（一个大概数量）。华为应用商店首页SQL 优化项目初期，可能并发不大，且开发时间短促，一切为了尽快上线。这时候缓存都来不及使用，那么只需要优化好 SQL 即可：select * from tb_app where app_id in(?, ?, ?)SQL 如上，.