wmd看海的博客

微服务架构：微服务化后系统架构要如何改造？随着业务功能的增加，当前系统依赖资源的扩展出现问题，一体架构在研发正本，部署成本上带来问题时，考虑将一体架构做微服务化拆分。在对服务进行拆分的过程中，需要考虑的问题：服务拆分要遵循哪些原则服务的边界如何确定微服务化后会带来哪些问题，如何解决这些问题。1 微服务拆分的原则1.1 单一服务内部功能的高内聚和低耦合每个服务只完成自己职责之内的任务，对于不是自己职责的功能交个其他服务来完成1.2 需要关注服务拆分的粒度，先粗略拆分再逐渐细化。拆分初期

系统架构：每秒1万次请求的系统要做成服务化拆分吗？DAU(Daily Active User)日活跃用户数量1 一体化架构的痛点项目刚开始的时候，为了尽快搭建项目，尽快上线，一般都采用一体化架构，即单体应用。开发简单直接，代码和项目集中式管理只需要维护一个工程，节省维护系统运行的人力成本排查问题的时候，只需要排查这个应用进程就可以了，目标性强但是随着系统功能越来越复杂，开发团队越来越大，一体化架构的缺陷也就显露出来了技术层面，数据库连接数可能成为系统的瓶颈研发成本上，团队增加导

消息队列，如何降低消息队列系统中消息的延迟当项目中引入了消息队列时，增加了系统的复杂度。需要考虑如何保证消息不会丢失、如何避免消息重复带来的影响、还需要考虑消息延迟情况，即消费性能的问题。场景：上游服务器产生订单数据，并将数据放入消息队列服务中，但是下游系统消费较慢，造成消息队列出现大量堆积。下游系统处理消息出现了延迟。如何来解决这个问题呢？监控消息的延迟减少消息延迟的正确做法1、如何监控消息延迟监控消息的延迟有两种方式：使用消息队列提供的工具，通过监控消息的堆积来完成监控通过生成监

消息投递：如何保证消息仅仅被消费一次由于系统引入了消息队列，可能出现 消息在投递的过程中发生丢失，1 消息可能在哪里丢失消息需要从生产者，到消息队列，到消费者。在整个链路中都有丢失的可能。消息从消费者写入到消息队列的过程消息在消息队列中的存储场景消息被消费者消费的过程1.1 在消息产生的过程中丢失信息消息的生产者一般是 业务服务器，消息队列是独立部署在单独的服务器上，两个服务之间一般通过内网进行交互，但是可能会出现网络抖动，消息因为网络错误而丢失。1.1.1 采用消息重传进行解决发现

1、场景分析在项目中遇到一些存在高并发写请求的场景，例如秒杀抢购。比如6.18，活动从0:00开始，仅限前 200 名，那秒杀即将开始时，后台会显示用户正在疯狂的刷新 APP或者浏览器来保证自己能够尽早的看到商品对于这种情况，你应该考虑什么呢？当秒杀开始前，用户在不断的刷新页面，系统应该如何应对高并发的读请求呢？在秒杀开始时，用户瞬间向系统请求生成订单，扣减库存，系统应该如何应对高并发的写请求呢？1.1、系统应该如何应对高并发的读请求使用缓存策略将请求挡在上层中的缓存中能静态化的

静态资源如何加速1、静态资源系统中存在大量的静态资源请求：对于APP来说，静态资源主要有图片、视频、流媒体Web网证主要包含 JavaScript文件、CSS文件、静态 HTML 文件就近访问来解决，在业务服务器的上层增加一层特殊的缓存，用来承担绝大部分对于静态资源的访问，这一层特殊缓存的节点需要遍布在全国各地，这样可以让用户选择最近的节点访问。缓存的命中率也需要一定的保证，尽量减少...

缓存的使用三-缓存穿透了如何解决在低缓存命中率的系统中，大量查询请求会穿透缓存到数据库，因为数据库对于并发的承受能力比较脆弱，导致查询变慢，大量请求阻塞在数据库查询上，造成应用服务器的连接和线程资源被占满，导致系统崩溃。1、缓存穿透的解决方案场景一通过用户ID查询用户的信息，缓存策略采用 Cache Aside 策略，如果读取一个用户表中未注册的用户会发生什么情况，我们会先读缓存再穿透读数...

缓存的使用二-缓存如何高可用为了减少数据库的压力，我们开始使用缓存承担大部分的读压力，在提升性能的同时也需要保证系统的稳定性。分布式缓存的高可用方案有以下几种：客户端方案中间代理方案服务端方案1、客户端方案写入数据时，需要把被写入缓存的数据分散到多个节点中，即进行数据分片读数据时，利用多组的缓存来做容错，有主从和多副本两种策略 来提升缓存系统的可用性1.1、缓存数据如何分...

缓存的使用一-如何选择缓存的读写策略缓存在实际项目中的使用，选择缓存策略时需要考虑不同的因素：缓存中是否有可能被写入脏数据策略的读写性能如何是否存在缓存命中率下降的情况1、Cache Aside（旁路缓存）策略更新数据时不更新缓存，而是删除缓存中的数据，在读取数据时，发现缓存中没有了数据之后，再从数据库中读取数据，更新到缓存中。这个策略是以数据中的数据为准，缓存中的数据是按需加载...

缓存：数据库成为瓶颈后，动态数据的查询如何加速在高并发大流量下，数据库层的演进过程、分库分表设计上的分析，基本可以支持十几万的 DAU （DAU(Daily Active User)日活跃用户数量）了。但是随着并发的增加，存储数据量的增多，数据库的磁盘 IO 逐渐成了系统的瓶颈，这个时候就需要使用缓存，来降低请求响应时间，提升系统的性能。1、缓存的定义存储数据的组件，作用是让对数据的请求更...

NoSQL补充数据库Redis、LevelDB KV存储，相比传统的数据库优势是极高的读写性能，一般对性能比较高的要求的场合会使用Hbase、Cassandra 列式存储数据库。适用于一些离线数据统计的场景MongoDB、CouchDB 文档型数据库。Schema Free(模式自由)，数据表中的字段可以任意扩展，比如电商系统中商品有非常多的字段，而且每个字段不同实际场景中发现，SQL...

1、分库分表后带来的问题查询的时候必须带着分区键字段一个聚合类查询性能比较差，需要考虑使用计数器等其他的解决方案主键的全局唯一性问题2、数据库中的主键要如何选择数据库中的每一条记录都需要有一个唯一的标识，依据数据库的第二范式，数据库中每一个表中都需要有一个唯一的主键，其他数据元素和主键一一对应。使用业务字段作为主键比如用户表中使用手机号码，email或者身份证号码作为主键...

1、写入数据量增加时，如何实现分库分表？数据使用单表存储，但是随着数据的增大，造成数据库查询、写入性能下降，数据库磁盘空间也发生报警，所以要解决这个问题，使得系统可以正常运转下去。1.1、需要考虑的问题系统正在持续不断的发展，数据库中存储的数据也越来越多，单个表的数据量超过了千万甚至亿级别。这时即使使用了索引，索引占用的空间也随着数据量的增长而增大，数据库就无法缓存全量的索引信息，那么就需...

查询请求增加时，如何做主从分离4核 8G 的机器上运行 MySQL 5.7是，大概可以支撑 500 的 TPS 和 10000 的QPS。1、主从读写分离将一个数据库中的数据拷贝为一份或者多份，并且写入到其他的数据库服务器中，原始的数据库我们称为是主库，主要负责数据的写入，拷贝的目标数据库为从库，主要负责支持数据查询。技术关键点为：1、数据的拷贝-主从复制2、在主从分离的情况下，如果屏蔽...

池化技术-如何减少频繁创建数据库连接的性能损耗1、池化技术池化技术的核心思想是空间换时间，期望使用预先创建好的对象来减少频繁创建对象的性能开销，同时还可以对对象进行统一的管理，降低了对象的使用成本。用连接池预先建立数据库连接数据库连接池HTTP连接池Redis连接池2、数据库连接池两个最重要的配置：最小连接数、最大连接数2.1、流程如果当前连接数小于最小连接数，则创建新的...

在热点事件发生时，流量瞬间提升到 2~3倍甚至更高，最快的方式就是堆机器，但需要保证，在扩容了三倍的机器后，相应的系统也能支撑三倍的流量。1、为什么提升扩展性会很复杂集群系统中，不同的系统分层上可能存在一些瓶颈点，这些瓶颈点制约着系统的横向扩展能力，比如：系统的流量是每秒1000次请求，对数据库的请求量也是每秒1000次，如果流量增加了10倍，虽然系统可以通过扩容正常服务，但是数据库却成了瓶颈...

高可用(High Avaliability, HA)，指的是系统具备较高的无故障运行的能力。1、可用性的度量MTBFMTBF（Mean Time Between Failure）：平均故障间隔，代表两次故障的间隔时间，也就是系统正常运转的平均时间，这个时间越长，系统稳定性就越高MTTRMTTR（Mean Time To Repair）：故障的平均恢复时间，也就是平均故障的时间。这个值越...

1、高并发系统设计的三大目标：高性能、高可用、可扩展性能，反应了系统的使用体验，例如，同样承担每秒一万次请求的两个系统，一个响应时间是毫秒级的，一个是秒级别，这样它们带给用户的体验肯定不同的。可用性表示系统可以为正常服务用户的时间。类比一下，还是两个承担每秒一万次请求的两个系统，一个系统可以全年不停机、无故障；另一个隔三差五的宕机维护可扩展性，流量一般分为平时流量和峰值流量，峰值流量可能会...

随着业务越来越复杂，大量的代码纠缠在一起，会出现逻辑不清晰、各模块相互依赖、代码扩展性差、改动一处就牵一发而动全身等问题1、常见的分层1.1、MVC将用户视图和业务处理隔离开，并且通过控制器连接起来，很好的实现了表现和逻辑的解耦。1.2、另一种分层表现层，顾名思义嘛，就是展示数据结果和接受用户指令的，是最靠近用户的一层逻辑层里面有复杂业务的具体实现数据访问层则是主要处理和存储之间的...