4 Leon_Jinhai_Sun

尚未进行身份认证

我要认证

暂无相关简介

等级
TA的排名 389

弥补关系型数据库的不足,引入分布式存储

我们应用最多的主要还是关系型数据库,但是在有些场景中,关系型数据库不是很合适。所以我们会引入分布式存储系统,比如redis、mongoDB、cassandra、HBase等。根据不同的场景和数据结构类型,选择合适的分布式存储系统可以极大提高性能。分布式系统通过集群提供一个高容量、高并发访问、数据冗余融债的支持。...

2020-10-25 11:01:29

分布式架构的NoSQL

NoSQL 我们可以理解成Not Only SQL、或者是No SQL。 两种意思都是为了表达在大型网站中,关系型数据库可以解决大部分问题,但是对于不同内容的特征、访问特征、事务特征等对存储的要求是不一样的。NoSQL是定位于是文件系统和SQL关系型数据库之间的范畴。数据缓存大型网站内部都会用到一些数据缓存,主要用于分担数据库的读的压力,缓存系统一般是用来保存和查询键值对的。应用系统中一般会把热点数据放入到缓存,而缓存的填充也应该是由应用系统完成。如果数据不存在,则从数据库独处数据后放入缓存。..

2020-10-25 10:57:26

分布式架构的分布式文件系统

对一些图片、大文本,使用数据库就不合适了,所以我们会采用分布式文件系统来实现文件存储,分布式文件系统有很多产品、比如淘宝的TFS、google的GFS。还有开源的HDFS

2020-10-25 10:54:24

加速数据读取的利器-缓存及分布式存储

在大型网站中,基本上就是在解决存储和计算的问题,所以存储是一个很重要的支撑系统。网站建设初期我们都是从关系型数据库开始的,而且很多时候为了方便,我们会把一些业务逻辑放在数据库里面去做,比如触发器、存储过程。虽然在前期能够很方便的解决问题,但是在未来的发展过程中会带来很多的麻烦,比如数据量大了以后,要做分库分表操作等.同时,业务发展到一定的体量以后,对存储的需求不能完全通过关系型数据库来满足...

2020-10-25 10:53:18

搜索引擎其实是一个读库

搜索引擎其实可以理解成一个读库,我们的商品存储在数据库中,而网站需要提供用户实时检索的功能,尤其是在商品搜索这块。对于这样的读请求,如果全部走读库,其实性能也会存在一个瓶颈。而使用搜索引擎,不仅仅能大大提高检索速度。还能减轻读数据库的压力而搜索引擎最重要的工作,就是需要根据被搜索的数据来构建索引,而随着被搜索的数据的变化,索引也需要相应变化。搜索集群的使用方式和读库的使用方式是一样的,只是构建索引的过程基本都是需要我们自己来实现。可以从两个纬度对搜索引擎构建索引的方式进行规划,一个是按照全量/增量划分.

2020-10-25 10:44:32

数据库压力变大,读写分离吧

随着业务的继续增长,数据量和访问量持续增加。对于大型网站来说,有不少业务是读多写少,这个情况也会直接反馈到数据库上。那么对于这种情况来说,我们可以考虑采用读写分离的方式来优化数据库的压力这个结构的变化会带来两个问题1. 数据如何同步我们希望通过读库来分担主库上读的压力,那么首先需要解决的是怎么复制到读库的问题。数据库系统一般都提供了数据复制的功能,我们可以直接使用数据库系统自身的机制。不同的数据库系统有不同的支持,比如Mysql支持Master+slave的结构提供数据复制机制2. ...

2020-10-25 10:24:53

将session维护在客户端

很容易想到就是利用cookie,但是客户端存在风险,数据不安全,而且可以存放的数据量比较小,所以将session维护在客户端还要对session中的信息加密。我们的Session数据放到Cookie中,然后在Web服务器上从Cookie中生成对应的Session数据。这就好比我们每次都把自己的碗筷带在身上,这样去那家饭店就可以随意选择了。相对前面的集中存储方案,不会依赖外部的存储系统,也就不存在从外部系统获取、写入Session数据的网络时延、不稳定性了。存在问题:安全性。Session数...

2020-10-25 10:12:08

分布式环境下的session共享

Session共享在当前这个互联网背景下,已经不是一个新鲜的话题了,而且如何解决session共享其实也有很多非常成熟的方案服务器实现的session复制或session共享,这类型的共享session是和服务器紧密相关的我们在Web服务器之间增加了会话数据的同步,通过同步就保证了不同Web服务器之间Session数据的一致。一般应用容器都支持Session Replication方式存在问题:1. 同步Session数据造成了网络带宽的开销。只要Session数据有变化,就需要将数...

2020-10-25 10:09:03

分布式架构的session问题

我们打开一个网页,基本上需要浏览器和web服务器进行多次交互,我们都知道Http协议本身是无状态的,这也是http协议设计的初衷,客户端只需要简单的向服务器请求下载某些文件,无论是客户端还是服务器都没必要记录彼此过去的行为,每一次请求之间是独立的,好比一个顾客和一个自动售货机之间的关系一样.而实际上,我们很多的场景都需要带有状态的特性,因此聪明的我们引入了session+cookie机制来记住每次请求的会话。在会话开始时,给当前会话分配一个唯一的会话标识(sessionid),然后通过cookie.

2020-10-25 10:01:28

分布式架构的负载均衡算法

轮询(Round Robin)法将请求按顺序轮流分配到后台服务器上,均衡的对待每一台服务器,而不关心服务器实际的连接数和当前的系统负载缺点:当集群中服务器硬件配置不同、性能差别大时,无法区别对待随机法通过系统随机函数,根据后台服务器列表的大小值来随机选取其中一台进行访问。随着调用量的增大,其实际效果越来越接近于平均分配流量到后台的每一台服务器,也就是轮询法的效果优点:简单使用,不需要额外的配置和算法。缺点:随机数的特点是在数据量大到一定量时才能保证均衡,所以如果请求量有...

2020-10-25 09:56:43

引入负载均衡设备

服务路由,基于负载均衡设备来实现引入负载均衡器以后,会带来session相关的问题

2020-10-25 09:47:45

分布式架构的水平和垂直扩容

对于大型的分布式架构而言,我们一直在追求一种简单、优雅的方式来应对访问量和数据量的增长。而这种方式通常指的是不需要改动软件程序,仅仅通过硬件升级或者增加机器就可以解决。而这种就是分布式架构下的伸缩设计伸缩分为垂直伸缩和水平伸缩两种垂直伸缩:表示通过升级或者增加单台机器的硬件来支撑访问量以及数据量增长的方式,垂直伸缩的好处在于技术难度比较低,运营和改动成本也相对较低。但是缺点是机器性能是有瓶颈的,同时升级高性能的小型机或者大型机,成本是非常大的。这也是阿里去IOE的一个原因之一增加CPU核...

2020-10-25 09:45:59

应用服务器复杂告警,如何让应用服务器走向集群

假如说这个时候应用服务器的压力变大了,根据对应用的检测结果,可以针对性的对性能压力大的地方进行优化。我们这里考虑通过水平扩容来进行优化,把单机变为集群假如说这个时候应用服务器的压力变大了,根据对应用的检测结果,可以针对性的对性能压力大的地方进行优化。我们这里考虑通过水平扩容来进行优化,把单机变为集群应用服务器从一台变为两台,这两个应用服务器之间没有直接的交互,他们都依赖数据库对外提供服务,那么这个时候会抛出两个问题1. 最终用户对应两个应用服务器访问的选择对于这个问题,可以采用D...

2020-10-25 09:42:46

单机负载告警,数据库与应用分离

随着网站的开放,访问量不断增大,那么这个时候服务器的负载势必会持续升高,必须要才需一些办法来应付。这里先不考虑更换机器和各种软件层面的优化,先从架构的结构上来做一些调整。我们可以把数据库与应用从一台机器分到两台机器变化:网站从一台变成了2台,这个变化对我们来说影响非常小。单机的情况下,我们应用采用JDBC的方式来和数据库进行连接,现在数据库与应用分开了,我们只需要在配置文件中把数据库的地址从本机改成数据库服务器的ip地址就行。对于开发、测试、部署都没有影响调整以后我们能够缓解当前的...

2020-10-25 09:40:22

大型网站的架构演进从一个电商网站开始

为了更好的理解,我们用电商网站来举例,作为一个交易类型的网站,一定会具备用户(用户注册、用户管理)、商品(商品展示、商品管理)、交易(下单、支付)这些功能假如我们只需要支持这几个基本功能,那么我们最开始的架构应该可能是这样的这个地方要注意的是,各个功能模块之间是通过JVM内部的方法调用来进行交互的,而应用和数据库之间是通过JDBC进行访问。...

2020-10-25 09:34:26

分布式架构的本质

一个软件系统随着功能越来越多,调用量急剧增长,整个系统逐渐碎片化,越来越无序,最终无法维护和扩展,所以系统在一段时间的野蛮生长后,也需要及时干预,避免越来越无序。架构的本质就是对系统进行有序化重构,使系统不断进化那架构是如何实现无序到有序的呢?基本的手段就是分和合,先把系统打散,然后重新组合。分的过程是把系统拆分为各个子系统/模块/组件,拆的时候,首先要解决每个组件的定位问题,然后才能划分彼此的边界,实现合理的拆分。合就是根据最终要求,把各个分离的组件有机整合在一起,相对来说,第一步的拆分更难。.

2020-10-25 09:04:55

分布式架构的分类

架构一般可分业务架构、应用架构、技术架构1. 业务架构从概念层面帮助开发人员更好的理解系统,比如业务流程、业务模块、输入输出、业务域2. 应用架构从逻辑层面帮助开发落地系统,如数据交互关系、应用形式、交互方式,是的整个系统逻辑上更容易理解,步入大家熟知的SOA就属于应用架构的范畴3. 技术架构主要解决技术平台选型、如操作系统、中间件、设备、多机房、水平扩展、高可用等问题需要注意的是,系统或者架构首先都是为人服务的,系统的有序度高,用用逻辑合理,业务概念清晰是第一位。现在大家讨论更多的是技..

2020-10-25 09:08:57

Redis中的Cluster总结

优势1. 无中心架构。2. 数据按照slot 存储分布在多个节点,节点间数据共享,可动态调整数据分布。3. 可扩展性,可线性扩展到1000 个节点(官方推荐不超过1000 个),节点可动态添加或删除。4. 高可用性,部分节点不可用时,集群仍可用。通过增加Slave 做standby 数据副本,能够实现故障自动failover,节点之间通过gossip 协议交换状态信息,用投票机制完成Slave 到Master 的角色提升。5. 降低运维成本,提高系统的扩展性和可用性。不足1.

2020-10-24 17:44:52

Redis中的Cluster高可用和主从切换原理

当slave 发现自己的master 变为FAIL 状态时,便尝试进行Failover,以期成为新的master。由于挂掉的master 可能会有多个slave,从而存在多个slave 竞争成为master节点的过程, 其过程如下:1.slave 发现自己的master 变为FAIL2.将自己记录的集群currentEpoch 加1,并广播FAILOVER_AUTH_REQUEST 信息3. 其他节点收到该信息, 只有master 响应, 判断请求者的合法性, 并发送FAILOVER_AUTH_

2020-10-24 17:38:30

Redis中的数据迁移

因为key 和slot 的关系是永远不会变的,当新增了节点的时候,需要把原有的slot分配给新的节点负责,并且把相关的数据迁移过来。添加新节点(新增一个7297):redis-cli --cluster add-node 127.0.0.1:7291 127.0.0.1:7297新增的节点没有哈希槽,不能分布数据,在原来的任意一个节点上执行:redis-cli --cluster reshard 127.0.0.1:7291输入需要分配的哈希槽的数量(比如500),和哈希槽的来源节点

2020-10-24 17:32:41

查看更多

勋章 我的勋章
  • GitHub
    GitHub
    绑定GitHub第三方账户获取
  • 技术圈认证
    技术圈认证
    用户完成年度认证,即可获得
  • 新人勋章
    新人勋章
    用户发布第一条blink获赞超过3个即可获得
  • 阅读者勋章Lv2
    阅读者勋章Lv2
    授予在CSDN APP累计阅读博文达到7天的你,是你的坚持与努力,使你超越了昨天的自己。
  • 持之以恒
    持之以恒
    授予每个自然月内发布4篇或4篇以上原创或翻译IT博文的用户。不积跬步无以至千里,不积小流无以成江海,程序人生的精彩需要坚持不懈地积累!
  • 1024勋章
    1024勋章
    #1024程序员节#活动勋章,当日发布原创博客即可获得
  • 1024超级勋章
    1024超级勋章
    授予原创文章总数达到1024篇的博主,感谢你对CSDN社区的贡献,CSDN与你一起成长。
  • 勤写标兵Lv4
    勤写标兵Lv4
    授予每个自然周发布9篇以上(包括9篇)原创IT博文的用户。本勋章将于次周周三上午根据用户上周的博文发布情况由系统自动颁发。
  • 学习力
    学习力
    《原力计划【第二季】》第一期主题勋章 ,第一期活动已经结束啦,小伙伴们可以去参加第二期打卡挑战活动获取更多勋章哦。