理论
文章平均质量分 79
为了生活
一片星空~
毕业l来北京快一年的菜鸟
展开
-
Hibernate的悲观锁和乐观锁机
有些业务逻辑在执行过程中要求对数据进行排他性的访问,于是需要通过一些机制保证在此过程中数据被锁住不会被外界修改,这就是所谓的锁机制。Hibernate支持悲观锁和乐观锁两种锁机制。悲观锁,顾名思义悲观的认为在数据处理过程中极有可能存在修改数据的并发事务(包括本系统的其他事务或来自外部系统的事务),于是将处理的数据设置为锁定状态。悲观锁必须依赖数据库本身的锁机制才能真正保证数据访问的排他性,乐观锁,顾名思义,对并发事务持乐观态度(认为对数据的并发操作不会经常性的发生),通过更加宽松的锁机制来解决由于悲观锁排原创 2020-07-31 11:17:01 · 122 阅读 · 0 评论 -
主从数据库-简配版实现
基于ThinkPHP5.1.15+MySQL演示主从同步配置与读写分离解决方案。软件环境:ThinkPHP5.1.15+MariaDB 10.1.30(主服务器)+MySQL5.7(从服务器)+Win10两台服务器IP分别为:192.168.199.234、192.168.199.237,已经为两个数据库创建了相同账号密码的账户。首先我在TP项目的数据库配置文件中,设置了主从配置以及读写分离,配置代码如下:第二步,修改主服务器的MySQL配置文件my.ini,主要代码如下:第69行代码是启用二转载 2020-09-14 18:04:09 · 99 阅读 · 0 评论 -
主从数据库-主从同步理论
主从数据库数据同步原理:Mysql的 Replication 是一个异步的复制过程,从一个 Mysql instace(我们称之为 主库)复制到另一个 Mysqlinstance(我们称之 从库)。在 主库 与 从库 之间的实现整个复制过程主要由三个线程来完成,其中两个线程(Sql线程和IO线程)在 从库 端,另外一个线程(IO线程)在 主库 端。MySQL 复制的基本过程如下:从库 上面的IO线程连接上 主库,并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容;主库 接收到来自原创 2020-09-14 18:01:04 · 446 阅读 · 0 评论 -
理论--MySql主从数据库和读写分离
什么是主从数据库?主从数据库, 主要是主数据库将数据通过二进制的日志文件同步到从库。在大型的互联网项目中,通常数据库操作都是一个瓶颈,频繁的数据库操作,导致数据库处理不过来。这其中一个原因都是因为server是集群的,而数据库还是单台,所以导致两边处理能力相差甚远。许多的国内外大型互联网项目架构体系中,均采用了MySQL的主从数据库配置来实现查询负载、增强数据库处理能力。主从数据库是主库一旦有操作,就会记日志,从库通过监听日志,实现和主库的数据同步。可以一主多从。主从数据库是主库进行写操作,从库转载 2020-09-07 18:03:19 · 316 阅读 · 0 评论 -
高并发和高可用的常规理解
高并发与高可用究竟啥才是互联网架构“高并发”一、什么是高并发高并发(High Concurrency)是互联网分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计保证系统能够同时并行处理很多请求。高并发相关常用的一些指标有响应时间(Response Time),吞吐量(Throughput),每秒查询率QPS(Query Per Second),并发用户数等。响应时间:系统对请求做出响应的时间。例如系统处理一个HTTP请求需要200ms,这个200ms就是系统的响应时间。吞吐量:单位时间转载 2020-07-21 16:40:54 · 960 阅读 · 0 评论 -
数据库分区、分表、分库、分片
一、分区的概念数据分区是一种物理数据库的设计技术,它的目的是为了在特定的SQL操作中减少数据读写的总量以缩减响应时间。 分区并不是生成新的数据表,而是将表的数据均衡分摊到不同的硬盘,系统或是不同服务器存储介子中,实际上还是一张表。另外,分区可以做到将表的数据均衡到不同的地方,提高数据检索的效率,降低数据库的频繁IO压力值,分区的优点如下:1、相对于单个文件系统或是硬盘,分区可以存储更多的数据;2、数据管理比较方便,比如要清理或废弃某年的数据,就可以直接删除该日期的分区数据即可;3、精准定位转载 2020-07-19 15:38:38 · 357 阅读 · 0 评论 -
高并发量网站解决方案
一个小型的网站,可以使用最简单的html静态页面就实现了,配合一些图片达到美化效果,所有的页面均存放在一个目录下,这样的网站对系统架构、性能的要求都很简单。随着互联网业务的不断丰富,网站相关的技术经过这些年的发展,已经细分到很细的方方面面,尤其对于大型网站来说,所采用的技术更是涉及面非常广,从硬件到软件、编程语言、数据库、WebServer、防火墙等各个领域都有了很高的要求,已经不是原来简单的html静态网站所能比拟的。大型网站,比如门户网站,在面对大量用户访问、高并发请求方面,基本的解决方案集中在这样几转载 2020-07-19 15:33:14 · 109 阅读 · 0 评论 -
数据库读写优化的三种方式
数据库的这些性能优化,你做了吗?在互联网项目中,当业务规模越来越大,数据也越来越多,随之而来的就是数据库压力会越来越大。我们可能会采取各种方式去优化,比如之前文章提到的缓存方案,SQL优化等等,除了这些方式以外,这里再分享几个针对数据库优化的常规手段:「数据读写分离」与「数据库Sharding」。这两点基本上是大中型互联网项目中应用的非常普遍的方案了。下面我们来详细看一看,一、从读写分离到CQRS(图片来源阿里云)由于互联网业务场景,大多数是读多写少,因此进行数据库的读写分离是一件非常简单且有转载 2020-07-19 15:25:57 · 1517 阅读 · 0 评论 -
负载均衡的三种实现方式
不懂高性能的负载均衡设计?架构师带你飞在软件系统的架构设计中,对集群的负载均衡设计是作为高性能系统优化环节中必不可少的方案。负载均衡本质上是用于将用户流量进行均衡减压的,因此在互联网的大流量项目中,其重要性不言而喻。一、什么是负载均衡?早期的互联网应用,由于用户流量比较小,业务逻辑也比较简单,往往一个单服务器就能满足负载需求。随着现在互联网的流量越来越大,稍微好一点的系统,访问量就非常大了,并且系统功能也越来越复杂,那么单台服务器就算将性能优化得再好,也不能支撑这么大用户量的访问压力了,这个时候就需要转载 2020-07-19 15:20:52 · 33137 阅读 · 0 评论 -
架构设计之「数据库读写优化」
在互联网项目中,当业务规模越来越大,数据越来越多,随之而来的就是数据库压力会越来越大。慢慢就会发现,数据库层可能已经成为了整个系统的关键点和性能瓶颈了,因此实现数据层的高可用就成为了我们项目中经常要解决的问题。本文我们就来聊一聊如何实现数据存储层的高可用方案。在保障数据层的高性能与高稳定方面,最容易想到的方式就是对数据进行分片、多份、冗余等,很多架构的本质其实也是基于这几点来实现的。这里先不看细节,即先不管底层数据源是什么数据库,我们先只聊架构方案,因为无论底层是关系型数据库,还是NoSQL数据库,无论转载 2020-07-19 15:11:55 · 125 阅读 · 0 评论 -
架构设计之「数据库集群方案」
在之前的文章中,我们知道数据库服务可能已经成为了很多系统的性能关键点,甚至是瓶颈了。也给大家介绍了数据库服务器从主备架构、到主从架构、再到主主架构的基础方案。但如果单台机器已经不能满足完整业务数据存储的时候,我们就需要考虑采用多机甚至多中心的部署方案了。今天我们就再来聊一聊,在多机环境下,数据库集群的架构方案。同样,这里先不看细节,不管底层数据源是什么数据库,我们先谈架构方案。因为无论底层是 Mysql 还是 Redis、MongoDB,我们在架构设计上都是相通的。针对多机的架构,常见有如下做法:单转载 2020-07-19 15:10:38 · 249 阅读 · 0 评论 -
架构设计之「服务限流」(二)
1.微服务限流随着微服务的流行,服务和服务之间的稳定性变得越来越重要。缓存、降级和限流是保护微服务系统运行稳定性的三大利器。缓存的目的是提升系统访问速度和增大系统能处理的容量,而降级是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉,待高峰或者问题解决后再打开,而有些场景并不能用缓存和降级来解决,比如稀缺资源、数据库的写操作、频繁的复杂查询,因此需有一种手段来限制这些场景的请求量,即限流。比如当我们设计了一个函数,准备上线,这时候这个函数会消耗一些资源,处理上限是1秒服务3000个QPS,但如果实转载 2020-09-07 18:07:25 · 159 阅读 · 0 评论 -
微服务之服务网关
我们已经知道,在微服务架构中,不同的微服务可以有不同的网络地址,各个微服务之间通过互相调用完成用户请求,客户端可能通过调用N个微服务的接口完成一个用户请求。比如:用户查看一个商品的信息,它可能包含商品基本信息、价格信息、评论信息、折扣信息、库存信息等等,而这些信息获取则来源于不同的微服务,诸如产品系统、价格系统、评论系统、促销系统、库存系统等等,那么要完成用户信息查看则需要调用多个微服务,这样会带来几个问题:客户端多次请求不同的微服务,增加客户端的复杂性,认证复杂,每个服务都要进行认证;h转载 2020-07-19 14:55:25 · 539 阅读 · 0 评论 -
架构设计之「 微服务入门 」
微服务这几年不可谓不火,很多技术团队都开始在自己的项目上引入了微服务。一方面这些团队确实很好的推动了微服务的应用和发展,另一方面也可以看到一些盲目追技术热点的行为所带来的危害,比如很多中小团队对微服务的基础知识只是做了很浅显的了解就开始盲目的推动微服务的实施,最后导致了项目的失败。微服务要想做好是一个非常复杂的架构,今天就先只聊一聊微服务的一些基础架构,算是入门篇。一、什么是「 微服务 」?「 微服务 」由 Martin Fowler 提出,它是指一种软件架构风格。一个大型的系统可以由多个微服务组成,转载 2020-07-16 19:18:46 · 159 阅读 · 0 评论 -
微服务架构之「 容器技术 」
现在一聊到容器技术,大家就默认是指 Docker 了。但事实上,在 Docker 出现之前,PaaS社区早就有容器技术了,以 Cloud Foundry、OpenShift 为代表的就是当时的主流。那为啥最终还是 Docker 火起来了呢?因为传统的PaaS技术虽然也可以一键将本地应用部署到云上,并且也是采用隔离环境(容器)的形式去部署,但是其兼容性非常的不好。因为其主要原理就是将本地应用程序和启停脚本一同打包,然后上传到云服务器上,然后再在云服务器里通过脚本启动这个应用程序。这样的做法,看起来很理转载 2020-07-16 19:14:47 · 221 阅读 · 0 评论 -
微服务架构之「 服务注册 」
微服务架构是一个庞大复杂的工程,为什么说它庞大复杂呢?因为想要做好微服务,就必须先要建设好微服务所需的一系列基础设施和组件。我在前面的文章《架构设计之「 微服务入门 」》中已经初步介绍过了这些组件,包括:服务注册、服务网关、配置中心、服务框架、服务监控、服务追踪、服务治理等。只有将这些基础设施搭建完善了,微服务实践的道路才能走的稳、走的远。后面的文章中会依次把每一个基础组件都详细分析一下。今天我们就先挑选「 服务注册 」聊一聊。一、为什么需要「 服务注册 」?我们先来举一个生活中的例子:在以前互联网还转载 2020-07-16 19:10:41 · 163 阅读 · 0 评论 -
微服务架构之「 访问安全 」
应用程序的访问安全又是我们每一个研发团队都必须关注的重点问题。尤其是在我们采用了微服务架构之后,项目的复杂度提升了N个级别,相应的,微服务的安全工作也就更难更复杂了。并且我们以往擅长的单体应用的安全方案对于微服务来说已经不再适用了。我们必须有一套新的方案来保障微服务架构的安全。在探索微服务访问安全之前,我们还是先来回顾一下单体应用的安全是如何实现的。一、传统单体应用如何实现「访问安全」?下图就是一个传统单体应用的访问示意图:(图片来自WillTran在slideshare分享)在应用服务器里面,转载 2020-07-16 19:04:54 · 143 阅读 · 0 评论 -
微服务架构之「 监控系统 」
在微服务架构的系列文章中,前面已经通过文章分别介绍过了微服务的「服务注册 」、「服务网关 」、「配置中心 」,今天这篇文章我们继续来聊一聊另外一个重要模块:「 监控系统 」。因为在微服务的架构下,我们对服务进行了拆分,所以用户的每次请求不再是由某一个服务独立完成了,而是变成了多个服务一起配合完成。这种情况下,一旦请求出现异常,我们必须得知道是在哪个服务环节出了故障,就需要对每一个服务,以及各个指标都进行全面的监控。一、什么是「 监控系统 」?在微服务架构中,监控系统按照原理和作用大致可以分为三类(并非转载 2020-07-10 18:26:47 · 883 阅读 · 0 评论 -
微服务架构之「 调用链监控 」
「 调用链监控 」是在微服务兴起后才有的一种新流行的监控模式。因为在我们传统单体应用的项目中,不存在服务链/调用链的概念,所以也就根本没有调用链监控的需求了。当我们开始微服务架构之后,我们的很多服务变成分布式的了,并且我们对服务进行了拆分,拆分之后,用户的一个请求进来,会依次经过不同的服务节点进行处理,处理完成后再返回结果给用户。那么在整个处理的链条中,如果有任何一个节点出现了延迟或者问题,都有可能导致最终的结果出现异常,有的时候不同的服务节点甚至是由不同的团队开发的、部署在不同的服务器上,那么在这么错.转载 2020-07-10 18:20:35 · 603 阅读 · 0 评论 -
微服务架构之「 容错隔离 」
我们知道,在单体应用的架构下一旦程序发生了故障,那么整个应用可能就没法使用了,所以我们要把单体应用拆分成具有多个服务的微服务架构,来减少故障的影响范围。但是在微服务架构下,有一个新的问题就是,由于服务数变多了,假设单个服务的故障率是不变的,那么整体微服务系统的故障率其实是提高了的。比如:假设单个服务的故障率是0.01%,也就是可用性是99.99%,如果我们总共有10个微服务,那么我们整体的可用性就是99.99%的十次方,得到的就是99.90%的可用性(也就是故障率为0.1%)。可见,相对于之前的单体应用,转载 2020-07-09 18:04:06 · 214 阅读 · 0 评论 -
微服务架构之「 配置中心 」
在微服务架构的系列文章中,前面已经通过文章《微服务架构之「服务网关 」》介绍过了在微服务中服务网关的原理和应用,今天这篇文章我们继续来聊一聊微服务中另外一个重要模块:「 配置中心 」。后面还会继续介绍 服务框架、服务监控、服务治理等。还是那句话,只有将这些基础设施弄清楚了,微服务实践的道路才能走的稳、走的远。「配置中心」,顾名思义,就是用来统一管理项目中所有配置的系统。虽然听起来很简单,但也不要小瞧了这个模块。如果一个中型互联网项目,不采用配置中心的模式,一大堆的各类配置项,各种不定时的修改需求,一定会让转载 2020-07-09 17:58:35 · 252 阅读 · 0 评论 -
架构设计之「服务限流」
什么是「服务限流」呢?在解释「服务限流」之前,我们来看一下前些时间网上很火的一个段子,说的是新浪微博的一名工程师正在家里办婚礼,突然接到公司的电话要紧急处理线上流量激增的问题,那天应该是某当红明星突然在微博上公布恋情,微博流量突增好几倍,导致系统功能出现不稳定,用户访问不畅。然后这名工程师就只好晾开新娘,在婚礼现场穿着西装打开笔记本调试代码了。当时这名工程师内心肯定是崩溃的,肯定在想:为啥要在今天公布恋情!等我把系统的扩容和服务限流机制做好先啊。哈哈,看完了段子,基本上服务限流的作用也就明白:服务限转载 2020-07-09 18:00:38 · 131 阅读 · 0 评论