Mobabel

Just One Pure ITer

Category: Build High Performance System

[转]高并发下的接口幂等性如何实现 0

Build High Performance System

[转]高并发下的接口幂等性如何实现

1. 一、背景 我们实际系统中有很多操作，是不管做多少次，都应该产生一样的效果或返回一样的结果。 例如1. 前端重复提交选中的数据，应该后台只产生对应这个数据的一个反应结果；2. 我们发起一笔付款请求，应该只扣用户账户一次钱，当遇到网络重发或系统bug重发，也应该只扣一次钱；3. 发送消息，也应该只发一次，同样的短信发给用户，用户会哭的；4. 创建业务订单，一次业务请求只能创建一个，创建多个就会出大问题等等很多重要的情况都需要幂等的特性来支持。

[转]当我们在谈论高并发的时候究竟在谈什么? 0

Build High Performance System

[转]当我们在谈论高并发的时候究竟在谈什么?

1. 什么是高并发?

那么我们在谈论高并发的时候，究竟在谈些什么东西呢？

[转]百万并发中间件系统的内核设计看Java并发性能优化 0

Build High Performance System

[转]百万并发中间件系统的内核设计看Java并发性能优化

（1）大部分人对Java并发仍停留在理论阶段 （2）中间件系统的内核机制：双缓冲机制 （3）百万并发的技术挑战 （4）内存数据写入的锁机制以及串行化问题 （5）内存缓冲分片机制 + 分段加锁机制 （6）缓冲区写满时的双缓冲交换 （7）且慢！刷写磁盘不是会导致锁持有时间过长吗？ （8）内存 + 磁盘并行写机制 （9）为什么必须要用双缓冲机制？ （10）总结 “ 这篇文章，给大家聊聊一个百万级并发的中间件系统的内核代码里的锁性能优化。很多同学都对Java并发编程很感兴趣，学习了很多相关的技术和知识。比如volatile、Atomic、synchronized底层、读写锁、AQS、并发包下的集合类、线程池，等等。

[转]亿级流量架构系列专栏总结[3] 数据一致性重构指南 0

Build High Performance System

[转]亿级流量架构系列专栏总结[3] 数据一致性重构指南

亿级流量系统架构之如何保证百亿流量下的数据一致性（上） 亿级流量系统架构之如何保证百亿流量下的数据一致性（中） 亿级流量系统架构之如何保证百亿流量下的数据一致性（下）   如何保证消息中间件全链路数据100%不丢失（1） 如何保证消息中间件全链路数据100%不丢失（2） 消息中间件如何实现消费吞吐量的百倍优化 如何保证生产者投递到消息中间件的消息不丢失  

[转]亿级流量架构系列专栏总结[2]架构可扩展性 0

Build High Performance System

[转]亿级流量架构系列专栏总结[2]架构可扩展性

在《亿级流量系统架构》系列第一阶段中，我们从零开始，讲述了一个大型数据平台的几个方面的构建，包括： 如何承载百亿级数据的存储挑战 如何承载设计高容错的分布式架构 如何设计高性能架构，使之能承载百亿级流量 如何设计高并发架构，能够支撑住每秒数十万的并发查询 如何设计全链路99.99%的高可用架构 好！架构演进到这个时候，系统是否无懈可击了呢？

[转]蚂蚁金服亿级并发下的移动端到端网络接入架构解析 0

Build High Performance System

[转]蚂蚁金服亿级并发下的移动端到端网络接入架构解析

1. 前言 支付宝移动端架构已完成了工具型 App、平台型 App，以及超级 App 三个阶段的迭代与逐步完善。 本次分享将聚焦支付宝在移动网络接入架构的具体演进，以及应对新春红包等项目在亿级并发场景下的具体应对之道。此外，我们将延展探讨蚂蚁金服移动网络技术如何对外商业化应用和输出。

[转]高并发的三个经典问题 0

Build High Performance System

[转]高并发的三个经典问题

1、单台服务器最大并发 单台服务器最大并发问题，一般是指一台服务器能够支持多少 TCP 并发连接。 一种理论说法是受到端口号范围限制。操作系统上端口号 1024 以下是系统保留的，从 1024-65535 是用户使用的。由于每个 TCP 连接都要占一个端口号，所以我们最多可以有 60000 多个并发连接。 但实际上单机并发连接数肯定要受硬件资源（内存、网卡）、网络资源（带宽）的限制。特别是网卡处理数据的能力，它是最大并发的瓶颈。

[转]消除单点 0

Build High Performance System

[转]消除单点

1. 系统架构中，为什么会存在单点？ (1)存在设计缺陷，出现了单点； (2)能大大简化系统设计，有意为之，设置单点；   典型互联网高可用架构，哪些地方可能存在潜在单点？ 典型互联网高可用架构： (1)端，通过DNS，由域名拿到nginx的外网IP； (2)反向代理，nginx是后端入口； (3)站点应用，典型的是tomcat或者apache； (4)服务，典型的是dubbo提供RPC服务调用； (5)数据层，典型的是读写分离的db架构；

0

Build High Performance System

[转]大规模集群任务调度

常见的调度系统往往兼顾了准确度却牺牲了性能，容器调度的复杂性使得很难在准确和效率之间找到平衡点，尤其是在交互式调度的场景下，可取的解决方案更是捉襟见肘。 随着分布式计算集群规模的不断扩张，任务调度系统的稳定性成为了整个集群稳定的关键因素。随着容器技术的快速兴起，基于容器的计算平台被大量应用，任务调度的规模及频率快速上升，这对任务调度系统提出了更为严苛的挑战。 常见的调度系统往往兼顾了准确度却牺牲了性能，容器调度的复杂性使得很难在准确和效率之间找到平衡点，尤其是在交互式调度的场景下，可取的解决方案更是捉襟见肘。本篇文章就以此为背景，介绍大规模调度场景下分布式任务调度的难点、解决策略及现有的一些方案。