yjc0403的博客

App架构总结        架构因人而异，不同的架构师大多会有不同的看法；架构也因项目而异，不同的项目需求不同，相应的架构也会不同。然而，有些东西还是通用的，是所有架构师都需要考虑的，也是所有项目都会有的需求，比如API如何设计？架构如何分层？开发环境和生产环境如何分离？而以下内容就是根据我的这些经历提炼出来的关于以上几个问题方面的经验总结，内容不多，旨在抛砖引玉。  ...

互联网一致性架构设计 -- DB主从一致性  需求分析        大部分互联网的业务都是 “ 读多写少 ” 的场景，数据库层面，读性能往往成为瓶颈。如下图：业界通常采用 “ 一主多从，读写分离，冗余多个读库 ” 的数据库架构来提升数据库的读性能。     这种架构的一个潜在缺点是，业务方有可能读取到并不是最新的旧数据： 系统先对DB-master进行了...

互联网一致性架构设计 -- DB双主一致性         MySQL数据库集群常使用一主多从，主从同步，读写分离的方式来扩充数据库的读性能，保证读库的高可用，但此时写库仍然是单点。        解决方法        在一个MySQL数据库集群中可以设置两个主库，并设置双向同步，以冗余写库的方式来保证写库的高可用。    需求分析  ...

互联网一致性架构设计 -- DB和Cache一致性  需求分析 下面两种情况会出现脏数据：     单库情况下     服务层的并发读写，缓存与数据库的操作交叉进行，这种情况虽然少见，但理论上是存在的，后发起的请求B在先发起的请求A中间完成了。     1. 请求A发起一个写操作，第一步淘汰了cache，然后这个请求因为各种原因在服务层卡住了（进行...

互联网一致性架构设计 -- 冗余表数据一致性  需求分析        互联网很多业务场景的数据量很大，此时数据库架构要进行水平切分，水平切分会有一个patition key，通过patition key的查询能够直接定位到库，但是非patition key上的查询可能就需要扫描多个库了。 例如订单表，业务上对用户和商家都有订单查询需求：     Order...

互联网一致性架构设计 -- 消息时序一致性  为什么时序难以保证，消息一致性难？      原因 时钟不一致多客户端（发送方）服务集群（多接收方）网络传输与多线程     时钟不一致        分布式环境下，有多个客户端、有web集群、service集群、db集群，他们都分布在不同的机器上，机器之间都是使用的本地时钟，而没有一...

互联网一致性架构设计 -- 事务一致性  按业务区分 单库事务多库事务     例子：用户下了一个订单，需要修改余额表，订单表，流水表     单库事务 start transaction; CURDtable t_account; any Exception rollback; CURDtable ...

互联网一致性架构设计 -- 库存扣除一致性  业务复杂、数据量大、并发量大的业务场景下，典型的互联网架构，一般会分为这么几层：调用层，一般是处于端上的browser或者APP站点层，一般是拼装html或者json返回的web-server层服务层，一般是提供RPC调用接口的service层数据层，提供固化数据存储的db    扣除库存的过...

分布式ID生成方法  需求分析     几乎所有的业务系统，都有生成一个记录标识的需求，例如： 消息标识：message-id订单标识：order-id帖子标识：tiezi-id    这个记录标识往往就是数据库中的唯一主键，数据库上会建立聚集索引（cluster index）  聚集索引：物理存储上以这个字段排序。非聚集索引：普通索...

分布式应用雪崩效用  对雪崩效用的理解        服务C依赖服务B，服务B依赖服务A，当服务A挂掉，这样服务B的请求一直等待，到超时为止，导致服务B的资源耗尽。    雪崩效用的原因 服务提供者不可用重试加大流量服务调用者不可用  服务提供者不可用的原因 硬件故障：服务器宕机或者网络故障程序bug缓存...

互联网一致性架构设计 -- session一致性  session是什么        服务器为每个用户创建一个会话，存储用户的相关信息，以便多次请求能够定位到同一个上下文。        Web开发中，web-server可以自动为同一个浏览器的访问用户自动创建session，提供数据存储功能。最常见的，会把用户的登录信息、用户信息存储在session中，以保持登...

缓存架构设计  需求分析     缓存是一种提高系统读性能的常见技术，对于读多写少的应用场景，我们经常使用缓存来进行优化。     例如对于用户的余额信息表account(uid, money)，业务上的需求是： 查询用户的余额，SELECT money FROM account WHERE uid=XXX，占99%的请求更改用户余额，UPDATE a...

加密解密的学习  读《图解密码技术》(一):密码读《图解密码技术》(二):认证读《图解密码技术》(三):密钥、随机数和应用技术

关于HTTP和HTTPS的安全问题  普通HTTP请求存在的问题       HTTP 本身是明文传输的，没有经过任何安全处理。例如用户在百度搜索了一个关键字，比如“苹果手机”，中间者完全能够查看到这个信息，并且有可能打电话过来骚扰用户。也有一些用户投诉使用百度时，发现首页或者结果页面浮了一个很长很大的广告，这也肯定是中间者往页面插的广告内容。如果劫持技术比较低劣的话，用户...

互联网系统架构的变迁  参看人家的见解https://segmentfault.com/a/1190000008016139

如何构建一个安全, 稳定, 高效的互联网平台体系架构        构建一个比较完善的互联网平台体系架构，广义上可以归纳为：高可用性，高扩展性，高性能，高安全性。  高可用性        高可用性又可以分为硬件高可用和软件高可用，其最根本的原理就是解决单点问题。         硬件高可用：服务器、网络设备等都应该避免单点问题 服务器...

互联网项目架构  什么是架构设计       通俗的说，架构设计就像是小学考试中解答应用题的过程，但是解决的问题更复杂，构思设计的过程更庞大，解题的工作量更大。    项目的质量指标       软件开发的最终目标是使用代码去实现抽象的业务逻辑，然后根据下面的指标评价项目的好坏： 功能：功能目标是应用的基本要求，如果不能实现既定的功能逻...

互联网架构 -- 高可用  什么是高可用        高可用HA(High Availability)是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。  高可用标准 假设系统一直能够提供服务，我们说系统的可用性是100%。如果系统每运行100个时间单位，会有1个时间单位无法提供服务，我们说系统的可用性是9...

互联网架构 -- 高并发         高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。  高并发的标准 响应时间：系统对请求做出响应的时间。例如系统处理一个HTTP请求需要200ms，这个200ms就是系统的响应时间。吞吐量：单位时间内处理的请求数量。Q...

互联网架构 -- 负载均衡  什么是负载均衡        负载均衡(Load Balance)是分布式系统架构设计中必须考虑的因素之一，它通常是指，将请求/数据【均匀】分摊到多个操作单元上执行，负载均衡的关键在于【均匀】。    常见的负载均衡方案        常见互联网分布式架构分为：客户端层、反向代理nginx层、站点层、服务层、数据层。可...

DNS轮询是否可被完全替代  有人会有以下观点 nginx前端加入lvs和keepalived可以替代“DNS轮询”F5能搞定接入层高可用、扩展性、负载均衡，可以替代“DNS轮询”    “DNS轮询”究竟是不是过时的技术，是不是可以被其他方案替代，接入层架构技术演进，是本文将要细致讨论的内容。    问题域     nginx、lvs...

分布式事务解决方案  https://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.htmlhttp://www.infoq.com/cn/articles/solution-of-distributed-system-transaction-consistencyhttp:/...