标签：架构 后端 数据库 QUERYDB 服务器 数据 PostgreSQL SSB
无论是开发语言的选择、代码的架构，服务器的搭配、网络的架构、数据库的架构还是第三方软件的选用等，每一方面都是个很大的方向，每个方向都值得一个人去研究一辈子
加小助理v：xiehuangbao1123 领取java学习资料和最新面试资料
Oracle
传统行业，尤其是政府，医疗，学校和大企业，基本上还是Oracle应用最广，其次就是DB2。反而是WebLogic和WebSphere这些中间件基本上随着经典javaee的没落，已经逐步退出历史舞台，被富前端和微服务框架的轻量级组合所替代。
MySQL
传统行业的很多新项目也大量开始应用MySQL，因为轻量级数据库的前期成本很低，可以保证项目预算够用，所以主要是新项目居多，面向互联网连接的项目也居多。这些系统一般不会像Oracle一样承担关键性业务的数据存储，所以选择什么样的数据库都是开发公司自己的选择决定。
目前有大量企业都开始上云，大家买云服务以阿里云ecs为主，总体上阿里云还是比较稳定，那么对于云上数据库的稳定有要求的企业一般都会选择阿里云主打的的rds系列，MySQL居多，PostgreSQL也开始逐渐被认可。
PostgreSQL
说到PostgreSQL，的确这两年PG风头正劲，以前我的文章也提到过我做过的互联网医疗产品，其架构设计就选择采用了PostgreSQL，主要就是看中PostgreSQL在生产上的稳定性极高，而且成本很低。尤其是精通Linux服务的架构师，对于PostgreSQL更容易掌握。
更具体地说就是使用PostgreSQL的关键因素主要还是业务数据很关键，因为我们当时承载的是互联网医疗数据，医疗数据自身属性就很关键！所以稳定和安全都是刚性要求，同时要平衡成本与互联网方式的灵活性，所以才否定了MySQL方案，坚决执行PostgreSQL方案。
Hadoop HDFS
大数据类项目的主数据集还是以Hadoop HDFS作为基础存储设施。尽管现在很热的讨论就是Hadoop已经是日落黄昏，可以选择其他更快的NoSQL存储方案。实际上，大数据工程师在最终落地的执行上，还是很诚实的选择了Hadoop，因为其成熟度，稳定性是最终考量的标准。
Elasticsearch
ELK家族的Elasticsearch目前被大量作为日志监测分析的主数据集去使用，甚至都忽视了它本身是搜索引擎的这个事实，在电子商务网站，内容发布网站以及社交媒体网站，Elasticsearch作为专业搜索引擎，还是稳坐第一把交椅。
实时/时序数据库
工业能源以及其他物联网行业，实时、时序数据库正在逐步采用开源的解决方案，例如Druid.io、InfluxDB，OpenTSDB，还是目前存储物联网数据最好的开源选择方案。Druid.io是实时与历史一整套实时库解决方案；InfluxDB目前热度非常高的时序数据库，自己独立实现了一套原生的集群存储结构；OpenTSDB主要依赖HBase分布式数据库与HDFS分布式文件系统。另外提一句，清华推出的开源时序数据库IOTDB，目前已经升级成Apache.org的顶级项目。
Hadoop HBase：Hadoop hbase
作为列簇存储，也是毫秒级的k-v存储，越来越适应通用场景下的实时数据分析了，可能哪个领域都有能用到它，支撑实时处理的联机分析以及小型批处理业务。它的分布式一致性，存储hdfs的稳定性，都是关键性业务数据进行实时分析的极佳方案。
TiDB
在互联网海量数据查询，保证事务一致性以及大吞吐写入并行的时代，就会形成两种模式，一种是NewSQL对关系型数据库的替代方案，以前我的文章也不断提到TiDB对关系数据库替代的必要性，这种替换行为一般会出现在基于关系数据库的上层复杂业务不断升级更新带来的问题，导致运维过程中相关人员生无可恋的情况。那么NewSQL这种分布式一致性，满足ACID，又带有k-v水平伸缩存储的方案就极为合适，不用在关系数据库的分库分表的泥潭中挣扎。
MongoDB
另一种是关系数据库自身的改进或者引入MongoDB进行部分替代，例如电子商务的订单业务数据，互联网医疗的健康档案数据，内容发布的文章数据，都能实现MongoDB的文档化替代，这不仅更符合业务的文档化模型，而且能保证事务的前提下，实现海量数据的支撑。
关系数据库并行能力
关系数据库也是在不断改进中前进，尤其是轻量级数据库的改进，MySQL8的cluster特性，PostgreSQL11的并行特性，都是不同手段想要达到同一个目的：那就是关系库都在想尽一切办法，不必让用户脱离关系型数据库，非得拥抱NoSQL才能追求到海量数据的并行处理能力，同时也能降低用户替换导致的巨大升级成本。
延伸：数据库架构
数据库架构需要考虑的问题：
- 数据可靠和一致性；
- 数据容灾；
- 当数据量和访问压力变大时，方便扩充；
- 高度可用，出问题时能及时恢复，无单点故障；
- 不应因为某一台机器出现问题，导致整网性能的急剧下降；
- 方便维护；
关于下面架构的说明：
- 核心服务器采用Cluster，还采用了SSD做磁盘阵列（SSD可存放索引等数据）；
- 核心服务器的数据变更通过SSB，分发到两台Replication的主机中（这一步可以先对数据进行粗加工，加工成方便用户查询的数据形式，然后再通过SSB包装后分发），使用了两台SSB分发机，既可以分担压力，也可以实现无单点故障；SSB可用保证核心库的数据和Replication主机数据一致；当然这一步也可以直接使用Replication来实现，但对核心服务器的压力会有所增加；
- 接下来将Replication主机的数据通过分发服务器分别分发到三台订阅机，也就是QUERYDB服务器；
- 六台QUERYDB通过F5控制访问，同时在前段加了台MemoryCache的服务器，增加缓存，减少查询的压力（这一部分很多公司使用了搜索引擎方面的技术，将数据库中的数据生成XML文件，再通过索引文件来查找数据）；
- B3和B4两台SSB的作用是做QUERYDB到核心服务器的SSB消息转发，SSB消息既能从QUERYDB发送到核心服务器，同时也能从核心服务器发送到QUERYDB；
这样有啥用呢？用处大了，因为核心服务器只有一台，我们如果把网站的所有操作都集中到核心服务器处理，那在业务高峰时期，数据变更非常频繁，核心服务器压力必定非常大，很可能抗不住。
为预防这样的问题，我们势必要把部分压力分担出去，于是我们可以在用户做注册、下单等操作时，先将操作放到QUERYDB中，再通过SSB把消息发送给核心服务器。
核心服务器接受到SSB消息后，会先放到队列中，然后一个个处理，这样核心服务器就不会因为同时处理过多的请求，而产生当机的风险，同时核心服务器处理完信息后，会将这些数据的变动通过Replication分发到每台QUERYDB中去。
这样QUERYDB的数据还是会和核心服务器保持一致，实现了通过QUERYDB来记录操作，然后运用SSB技术来分压的效果；因为QUERYDB有六台（还可以扩展），QUERYDB上SSB压力都分散了，所以也不会给QUERYDB带来很大的压力（可能消息会有小的延时，应该尽量在SSB通道上使用光纤网络）； - 即便核心服务器当机了，还是可以进行查询数据、注册和下订单等操作，SSB会一直保留消息。
- 架构2是两个异地机房之间的架构，和架构1类似。
如果文章有错的地方欢迎指正，大家互相交流。想要获取更多的Java学习资料和面试资料的同学，可以加v：xiehuangbao1123
标签：架构,后端,数据库,QUERYDB,服务器,数据,PostgreSQL,SSB 来源： https://blog.csdn.net/X6954636/article/details/118032527
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。