木瓜煲鸡脚's blog

超长警告！！！善用目录！！！ [TOC] 一、微服务架构1.1 互联网应用架构演进随着互联⽹的发展，⽤户群体逐渐扩大，⽹站的流量成倍增⻓，常规的单体架构已⽆法满⾜请求压⼒和业务的快速迭代，架构的变化势在必⾏。下⾯我们就以拉勾网的架构演进为例，从最开始的单体架构分析，⼀步步的到现在的微服务架构。 淘宝：LAMP，Linux、Apache、MySQL、PHP 1.1.1 单体应用架构在诞⽣之初，拉勾的⽤户量、数据量规模都⽐较⼩，项目所有的功能模块都放在一个工程中编码、编译、打包并且部署在一个Tomcat容器中的架构模式就是单体应用架构，这样的架构既简单实 ⽤、便于维护，成本⼜低，成为了那个时代的主流架构⽅式。 优点： 高效开发：项⽬前期开发节奏快，团队成员少的时候能够快速迭代 架构简单：MVC架构，只需要借助IDE开发、调试即可 易于测试：只需要通过单元测试或者浏览器完成 易于部署：打包成单⼀可执⾏的jar或者打成war包放到容器内启动 单体架构的应用比较容易部署、测试， 在项目的初期，单体应用可以很好地运行。然而，随着需求的不断增加， 越来越多的人加入开发团队，代码库也在飞速 ...

题目信息 题目地址：https://leetcode-cn.com/problems/count-primes/ 统计所有小于非负整数 n 的质数的数量。 示例1： 123输入：n = 10输出：4解释：小于 10 的质数一共有 4 个, 它们是 2, 3, 5, 7 。 示例2： 12输入：n = 0输出：0 示例3： 12输入：n = 1输出：0 解法一：暴力枚举依题意需要统计0至n当中质数的个数，自然的就想的到去遍历0至n的每个数字，再判段每个数字是否是质数，如果是计数加一如果不是则不变，最终返回计数结果。 对于判断是否是质数，我们都知道是有且只能被自己与1整除的数是质数（1不算），那么判断7是不是质数需要判断它能否被2至6里面的数整除么，其实不需要因为一个数不可能整除大于自己一半的数。也就是说判断数字number是否为质数看看2到number/2之间的整数能不能进行整除即可 了解之后我们先定义一个判断是否是质数的judge方法： 1234567public boolean judge(int number){ // 遍历2到number/2之间的 ...

超长警告！！！善用目录！！！ 一、SpringBoot基本应用1.1 约定优于配置 Build Anything with Spring Boot：Spring Boot is the starting point for building all Spring-based applications. Spring Boot is designed to get you up and running as quickly as possible, with minimal upfront configuration of Spring. ​ 上面是引自官网的一段话，大概是说： Spring Boot 是所有基于 Spring 开发的项目的起点。SpringBoot 的设计是为了让你尽可能快的跑起来 Spring 应用程序并且尽可能减少你的配置文件。 约定优于配置（Convention over Configuration），又称按约定编程，是一种软件设计范式。 本质上是说，系统、类库或框架应该假定合理的默认值，而非要求提供不必要的配置。比如说模型中有一个名为User的类，那么数据 ...

超长警告！！！善用目录！！！ 1. 什么是RabbitMQ1.1 MQ（Message Queue）消息队列 消息队列中间件，是分布式系统中的重要组件 主要解决，异步处理，应用解耦，流量削峰等问题 从而实现高性能，高可用，可伸缩和最终一致性的架构 使用较多的消息队列产品：RabbitMQ，RocketMQ，ActiveMQ，ZeroMQ，Kafka等 1.1.1 异步处理 用户注册后，需要发送验证邮箱和手机验证码； 将注册信息写入数据库，发送验证邮件，发送手机，三个步骤全部完成后，返回给客户端 1.1.2 应用解耦 场景：订单系统需要通知库存系统 如果库存系统异常，则订单调用库存失败，导致下单失败 原因：订单系统和库存系统耦合度太高 订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户，下单成功； 库存系统：订阅下单的消息，获取下单信息，库存系统根据下单信息，再进行库存操作； 假如：下单的时候，库存系统不能正常运行，也不会影响下单，因为下单后，订单系统写入消息队列就不再关心其他的后续操作了，实现了订单系统和库存系统的应用解耦； 所以说 ...

1. 场景概述 天猫，淘宝等购物网站，大量的图片和视频，文件太多，如何存储？ 用户访问量大又如何保证下载速度？分布式文件系统就是解决这些问题的！ 1.1 什么是文件系统 文件数据是如何存储的？？ 1.2 分布式文件系统 一台电脑存储量有限，并且并发吞吐量也有限，如何提高性能？ 一吨货物，我要运送到吐鲁番： 1个人运，不敢想象 50个人运，太难了； 500个人运，每个人都很轻松； 这就是分布式吗？ 这里面有集群的概念，也有分布式的概念，二者不要混淆，面试常问的经典题目 分布式：不同的业务模块部署在不同的服务器上或者同一个业务模块分拆多个子业务，部署不同的服务器上。解决高并发的问题； 集群：同一个业务部署在多台服务器上，提高系统的高可用 1.3 主流的分布式文件系统1.3.1 HDFS (Hadoop Distributed File System)Hadoop 分布式文件系统； 高容错的系统，适合部署到廉价的机器上； 能提供高吞吐量的数据访问，非常适合大规模数据应用； HDFS采用主从结构，一个HDFS是由一个name节点和N个data节点组成； name节点储存元数据，一 ...

一、概述1.1 互联网架构的演变历程 第1阶段 数据访问量不大，简单的架构即可搞定！ 第2阶段 数据访问量大，使用缓存技术来缓解数据库的压力。 不同的业务访问不同的数据库 第3阶段 主从读写分离。 之前的缓存确实能够缓解数据库的压力，但是写和读都集中在一个数据库上，压力又来了。 一个数据库负责写，一个数据库负责读。分工合作。愉快！ 让master（主数据库）来响应事务性**（增删改）操作，让slave（从数据库）来响应非事务性（查询）**操作，然后再采用主从复制来把master上的事务性操作同步到slave数据库中 mysql的master/slave就是网站的标配！ 第4阶段 mysql的主从复制，读写分离的基础上，mysql的主库开始出现瓶颈 由于MyISAM使用表锁，所以并发性能特别差 分库分表开始流行，mysql也提出了表分区，虽然不稳定，但我们看到了希望 开始吧，mysql集群 1.2 Redis入门介绍 互联网需求的3高 高并发，高可扩，高性能 Redis 是一种运行速度很快，并发性能很强，并且运行在内存上的NoSql（no ...

一、Zookeeper概述1.1 概述 美团，饿了么，淘宝，58同城等等应用都是zookeeper的现实生活版 老孙我开了个饭店，如何才能让大家都能吃到我们的饭菜？需要入驻美团，这样大家就可以在美团 app中看到我的饭店，下订单，从而完成一次交易 Zookeeper是一个开源的分布式（多台服务器干一件事）的，为分布式应用提供协调服务的Apache项目。 在大数据技术生态圈中，zookeeper（动物管理员），Hadoop（大象），Hive（蜜蜂），Pig（猪）等技术 1.2 工作机制 Zookeeper从设计模式角度来理解：是一个基于观察者模式（一个人干活，有人盯着他）设计的分布式服务管理框架 它负责 存储 和 管理 大家都关心的数据 然后接受观察者的注册，一旦这些数据的发生变化 Zookeeper就将负责通知已经注册的那些观察者做出相应的反应 从而实现集群中类似Master/Slave管理模式 Zookeeper = 文件系统 + 通知机制 商家营业并入驻 获取到当前营业的饭店列表 服务器节点下线 服务器节点上下线事件通知 重新再去获取服务器列表，并注 ...

一、Dubbo概述1.1 什么是分布式系统？ 《分布式系统原理与范型》定义： “分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像单个相关系统” 分布式系统（distributed system）是建立在网络之上的软件系统。 简单来说：多个（不同职责）人共同来完成一件事！ 任何一台服务器都无法满足淘宝的双十一的数据吞吐量，一定是很多台服务器公共来完成的。 歇后语：“三个臭皮匠赛过诸葛亮”，就是分布式系统的真实写照 1.1.1 单一应用架构 当网站流量很小时，只需要一个应用，将所有的功能部署到一起（所有业务都放在一个tomcat里），从而减少部署节点和成本； 此时，用于简化 增删改查 工作量的数据访问框架 （ORM）是关键； 例如：某个超市的收银系统，某个公司的员工管理系统 ORM：对象关系映射（Object Relational Mapping） 优点 小项目开发快 成本低 架构简单 易于测试 易于部署 缺点 大项目模块耦合严重 不易开发 维护 沟通成本高 新增业务困难 核心业务与边缘业务混合在一块，出现问题互相影响 1.1.2 垂直应用架构 当访问 ...