分布式存储

概述 互联网应用发展到今天，从单体应用架构到SOA以及今天的微服务，随着微服务化的不断升级进化，服务和服务之间的稳定性变得越来越重要，分布式系统之所以复杂，主要原因是分布式系统需要考虑到网络的延时和不可靠，微服务很重要的一个特质就是需要保证服务幂等，保证幂等性很重要的前提需要分布式锁控制并发，同时缓存、降级和限流是保护微服务系统运行稳定性的三大利器。 随着业务不断的发展，按业务域的划分子系统越来越多，每个业务系统都需要缓存、限流、分布式锁、幂等工具组件，distributed-tools组件(暂未开源)正式包含了上述分布式系统所需要的基础功能组件。 distributed-tools组件基于tair、redis分别提供了2个springboot starter，使用起来非常简单。 以使用缓存使用redis为例，application.properties添加如下配置 redis.extend.hostName=127.0.0.1 redis.extend.port=6379 redis.extend.password=pwdcode redis.extend.timeout=10000 redis.idempotent.enabled=true 接下来的篇幅，重点会介绍一下缓存、限流、分布式锁、幂等的使用方式。 缓存 缓存的使用可以说无处不在，从应用请求的访问路径来看，用户user

前言 今天老顾带着大家了解一下 session会话在微服务架构中采用的技术方案 ，以及 企业应用中需要注意的问题。 session作用 我们知道在web应用中， web服务器和浏览器之间是用http协议进行通信的 ，而 http协议是无状态 的，也就是 每个请求都是独立 的。如：用户看一条A新闻，不管是谁看到的都是一模一样的新闻。也就是 跟用户是谁没有任何关系 。 但业务自身的发展，需要把 不同的内容展示给不同的用户 ，即 信息和用户状态关联 起来。如：历史阅读列表---列出用户之前看的新闻。这个需求就是跟用户相关， 每个用户看到的历史阅读列表都是不一样的。 Session的产生 就是为了解决这个问题，把 服务器和客户端之间进行状态保持 的解决方案。 session原理 浏览器在第一次访问web服务器， 服务器端会响应一个sessionId，并且把这个sessionId传输给浏览器，并以cookie保存sessionId到浏览器本地 。 以后的访问会 把这个cookie的sessionId以请求头的方式传给服务器 ，这样服务器就可以拿着 这个sessionId进行查找，服务器中有没有此sessionId对应的用户 ，这样就能标识出哪个用户，如果有用户相关的业务，就是 利用这个sessionId返回用户相关的业务 。 本质就是 浏览器客户端本地保存了sessionId ，

摘自： https://www.cnblogs.com/powertoolsteam/p/redis.html Redis是什么？看这一篇就够了 本文由葡萄城技术团队编撰并首发 转载请注明出处： 葡萄城官网 ，葡萄城为开发者提供专业的开发工具、解决方案和服务，赋能开发者。 引言 在Web应用发展的初期，那时关系型数据库受到了较为广泛的关注和应用，原因是因为那时候Web站点基本上访问和并发不高、交互也较少。而在后来，随着访问量的提升，使用关系型数据库的Web站点多多少少都开始在性能上出现了一些瓶颈，而瓶颈的源头一般是在磁盘的I/O上。而随着互联网技术的进一步发展，各种类型的应用层出不穷，这导致在当今云计算、大数据盛行的时代，对性能有了更多的需求，主要体现在以下四个方面： 低延迟的读写速度：应用快速地反应能极大地提升用户的满意度 支撑海量的数据和流量：对于搜索这样大型应用而言，需要利用PB级别的数据和能应对百万级的流量 大规模集群的管理：系统管理员希望分布式应用能更简单的部署和管理 庞大运营成本的考量：IT部门希望在硬件成本、软件成本和人力成本能够有大幅度地降低 为了克服这一问题，NoSQL应运而生，它同时具备了高性能、可扩展性强、高可用等优点，受到广泛开发人员和仓库管理人员的青睐。 Redis是什么 Redis是现在最受欢迎的NoSQL数据库之一，Redis是一个使用ANSI

今年天猫双11当天，OceanBase数据库再次刷新数据库处理峰值，达6100万次/秒，创造了新的世界纪录。 在此之前一个月，据权威机构国际事务处理性能委员会TPC披露：蚂蚁金服的分布式关系数据库OceanBase，打破美国甲骨文公司保持了9年的世界纪录，成为首个登陆该榜单的中国数据库系统。 作为全球首个应用在金融核心系统的分布式关系数据库，蚂蚁金服OceanBase的出现，是金融科技发展过程中极为重要的一步。 事实上，蚂蚁金服OceanBase“登顶”之路绝非易事，却又是理想主义使然！正如马云所讲，“我不懂技术，但是我尊重技术。” 九年积淀缩影，一切从零开始 2008年，阿里巴巴集团首席架构师王坚提出“去IOE”，即摆脱业务系统对IBM小型机、Oracle数据库以及EMC存储的过度依赖。2009年开始，阿里举全公司之力投入到云计算的研发和使用中，随后在阳振坤带领下启动了OceanBase分布式关系数据库项目。 从2011年双11到2019年双11，自主研发的OceanBase数据库，以远低于传统商业数据库的成本，更高的可用性，一次次地刷新世界纪录，打破了核心数据库长期被传统商业数据库垄断的格局。 2017年，OceanBase数据库迈出了商业化关键的第一步，为南京银行“鑫云+”互金开放平台提供金融级分布式关系数据库服务。此后，OceanBase不仅在西安银行、广东农信、人保健康险

课程介绍 微服务架构的技术体系、社区目前已经越来越成熟。在最初系统架构的搭建，或者当现有架构已到达瓶颈需要进行架构演进时，很多架构师、运维工程师会考虑是否需要搭建微服务架构体系。虽然很多文章都说微服务架构是复杂的、会带来很多分布式的问题，但只要我们了解这些问题，并找到解法，就会有种拨开云雾的感觉。 微服务架构也不是完美的，世上没有完美的架构，微服务架构也是随着业务、团队成长而不断演进的。最开始可能就几个、十几个微服务，每个服务是分库的，通过 API Gateway 并行进行服务数据合并、转发。随着业务扩大、不断地加入搜索引擎、缓存技术、分布式消息队列、数据存储层的数据复制、分区、分表等。 本课程会一一解开微服务架构下分布式场景的问题，以及通过对于一些分布式技术的原理、模型和算法的介绍，来帮助想要实施微服务架构的工程师们知其然并知其所以然。并且，本课程通过对分布式问题的体系化梳理，结合一些方案的对比选型，可以让工程师们一览微服务的知识图谱。 注：为了方便初学者理解微服务实践，以及掌握怎样在微服务中使用 DDD（Domain-Driven Design）思想，在本课程第 05 课中讲解了 Demo 示例，该示例是基于 Spring Boot、Spring Cloud Eureka 技术写的，Microservice 代码详见这里，Gateway 代码详见这里。 专家推荐

写在前面 https://www.cnblogs.com/gengzhe/p/ray_actor.html Orleans是基于Actor模型思想的.NET领域的框架，它提供了一种直接而简单的方法来构建分布式大规模计算应用程序，而无需学习和应用复杂的并发或其他扩展模式。我在2015年下半年开始应用Orleans，当时公司的交易系统采用的架构就是基于Orleans框架的，其展现出来的高性能、高并发以及惊人的稳定性深深地吸引了我，也让我认识到了传统三层无状态架构的缺陷。本文主要关注Orleans的思想基础，Actor模型及其应用。 Orleans思想基础：Actor模型 传统三层无状态架构的缺陷 在讨论Actor模型之前，我们可以先讨论一下传统三层架构在当前高并发环境中所面临的尴尬境遇。 三层架构包括表示层、业务逻辑层或者叫做中间层、数据访问层（也就是存储层），其架构图如下所示： 正如我们在实践中所知道的那样，中间层和数据访问层在伸缩性方面有着很大的限制，同时存储层常常会成为系统的瓶颈，这就意味着整套系统也会因为存储层的限制而变得低效。通常的做法是在中间层与存储层中间加一层缓存逻辑出来，以提升系统性能，但是很快就会遇到存储层与缓存层的数据一致性问题，这无疑为开发人员和运维人员增加了额外的工作量。 试想一下，如果我们中间层本身就携带着状态或者简单来说中间层与缓存层是合二为一的

BaikalDB是一个分布式可扩展的存储系统，支持PB级结构化数据的随机实时读写。 提供MySQL接口，支持常用的SELECT，UPDATE，INSERT，DELETE语法。提供各种WHERE过滤、GROUP BY聚合，HAVING过滤，ORDER BY排序等功能，用户可以组合实现各种在线OLAP需求，具备秒级别的亿级数据扫描聚合能力。另外，为了满足各种业务的检索需求，该系统内置全文检索需求，满足大部分快速检索的业务场景。 在虚拟化部署方面，该系统采用share-nothing的架构，可部署在容器中，也实现了多租户隔离，有自定义用户的身份识别和权限访问控制等功能。 BaikalDB 的主要特性如下： 全自主化的容量管理，可以自动扩容和自动数据均衡，支持自动故障迁移，无单点，很容易实现云化，目前运行在Paas虚拟化平台之上。 面向查询优化，支持各种二级索引，包括全文索引，支持常用的 OLAP 需求，支持层级模型。 兼容 mysql 协议，对应用方提供 SQL 界面，支持高性能的Schema 加列。 基于 RocksDB 实现单机存储，基于Multi Raft 协议（我们使用braft库）保障副本数据一致性，基于brpc实现节点通讯交互。 支持多租户，meta 信息共享，数据存储完全隔离。 其中 BaikalStore 负责数据存储，用 region 组织，三个 Store 的

随着各个业务系统的不断增加，以及各业务系统数据量不断激增，业务用户的分析诉求越来越多且变化很快，IT数据支撑方的工作变得越来越复杂。 1、数据来自多个不同的系统，存在需要跨数据源分析，需要对接各种不同数据源等问题。 2、需要分析的数据体量越来越大，并且要快速获得分析结果的问题。 3、部分数据还需要二次加工处理的问题。 供数支撑方在业务系统的前端看起来基本没有任何操作，但背后的逻辑十分复杂，实现难度也很大。就像看得到的是冰山一角，看不到的是海水下绝大部分的支撑。 为了解决日益激增的大数据量分析诉求，大部分公司会通过搭建Hadoop、Spark等大数据架构，配以BI工具做数据层面的分析，来搭建这样一整套大数据分析平台。 大数据分析很关键的一个点在于性能：取数快不快，分析响应快不快，能否实时？ 这个问题除了平台的底层架构，BI（ 商业智能 ）的运行性能也有很大相关。 大家可能普遍认为的BI，就是一个数据展现工具，在前端看起来没有太多有技术含量的操作，但背后的逻辑十分复杂，实现难度也很大。就像看得到的是冰山一角，看不到的是海水下绝大部分的支撑。 好的BI工具都有与之依赖的数据引擎，数据引擎的作用一方面是数据响应的性能（数据量、速率），还有很重要的一点是能否适应企业不同业务情况的模式/方案。比如小数据快速读取，大数据分布式并行运算，节点数据实时展现等等..... FineBI V5

1、Zookeeper 的由来 在Hadoop生态系统中，许多项目的Logo都采用了动物，比如 Hadoop 和 Hive 采用了大象的形象，HBase 采用了海豚的形象，而从字面上来看 ZooKeeper 表示动物园管理员，所以大家可以理解为 ZooKeeper就是对这些动物（项目组件）进行一些管理工作的。 对于单机环境多线程的竞态资源协调方法，我们一般通过线程锁来协调对共享数据的访问以保证状态的一致性。 但是分布式环境如何进行协调呢？于是，Google创造了Chubby，而ZooKeeper则是对于Chubby的一个开源实现。 ZooKeeper是一种为分布式应用所设计的高可用、高性能且一致的开源协调服务，它提供了一项基本服务：分布式锁服务。由于ZooKeeper的开源特性，后来我们的开发者在分布式锁的基础上，摸索了出了其他的使用方法：配置维护、组服务、分布式消息队列、分布式通知/协调等。它被设计为易于编程，使用文件系统目录树作为数据模型。 2、ZooKeeper集群模式典型架构 2.1 角色 Zookeeper服务自身组成一个集群(2n+1个服务允许n>=1个失效)。Zookeeper集群是一个基于主从复制的高可用集群，每个服务器承担如下三种角色中的一种 Leader 一个Zookeeper集群同一时间只会有一个实际工作的Leader

页面架构： 系统使用 Nginx+Apache+Mysql+PHP 负载均衡 缓存系统 Memcached + Redis + File缓存 PHP 应用层框架 CodeIgniter 文件上传前端插件 WebUploader 【可以上传大文件，断点续传】 图片架构： 分布式存储集群MogileFS http://wangzan18.blog.51cto.com/8021085/1716499/ PHP扩展 MogileFS mogilefs-php扩展的安装配置 http://pecl.php.net/package/mogilefs # svn checkout http://svn.usrportage.de/php-mogilefs/trunk # cd trunk # phpize # ../configure --with-php-config=/opt/php/bin/php-config /** checking for PHP extension directory... /usr/local/php/lib/php/extensions/no-debug-non-zts-20060613 checking for PHP installed headers prefix... /usr/local/php/include/php checking if