简述什么是网站建筑公司网站模板免费下载

简述什么是网站,建筑公司网站模板免费下载,网站标题写什么作用是什么意思,十大互联网培训机构1. 业务场景适用场景#xff1a;数据查询缓慢#xff08;数据量大导致、数据聚合时调用外部系统过多导致等#xff09;写数据效率尚可所有数据都可能修改#xff08;若存在冷数据#xff0c;可使用上一章的冷热分离方案#xff09;基本思路#xff1a;将更新的数据放在主…1. 业务场景适用场景数据查询缓慢数据量大导致、数据聚合时调用外部系统过多导致等写数据效率尚可所有数据都可能修改若存在冷数据可使用上一章的冷热分离方案基本思路将更新的数据放在主数据库里而查询的数据放在另外一个专门针对搜索的存储系统里。主库单表查询无关联无外键所以写数据无压力。数据查询通过一个专门处理大数据量的查询引擎来解决。这里有同学可能会提到数据库读写分离这种情况下在千万级别数据量下的速度提升并不大并且只能解决数据库查询慢的问题不能解决其他如查询详情时调用外部系统耗时长导致的查询慢问题。核心问题如何触发查询分离如何实现查询分离查询数据如何存储查询数据如何使用历史数据如何迁移2. 查询分离2.1 如何触发查询分离1修改业务代码写入同时同步更新查询数据同步更新示意图图2-1: 同步更新查询数据示意图2修改业务代码在写入常规数据后异步更新查询数据异步更新示意图图2-2: 异步更新查询数据示意图3监控数据库日志如有数据变更则更新查询数据优点是不会影响业务代码。监控日志更新示意图图2-3: 监控数据库日志更新查询数据示意图优缺点对比优缺点对比表图2-4: 三种触发方式优缺点对比表针对优缺点总结适用场景适用场景总结图2-5: 三种方法适用场景总结2.2 如何实现查询分离这里以方法二业务代码异步更新查询数据的方式为例讲解实现方式这个方法需要考虑以下几个问题写操作较多且线程太多时需要加以控制否则太多线程最终会拖垮JVM创建查询数据的线程出错时如何自动重试如何标识更新失败的数据多线程并发时需要解决很多并发场景针对以上问题可以考虑使用MQ来解决在短时间线程过多时将任务暂存到MQ中间件进行削峰处理业务失败时可自动重新发送消息重试。MQ解决方案示意图图2-6: MQ解决方案架构示意图具体方案写操作时主数据表添加标识 NeedUpdateQueryDatatrueMQ消息简单只是一个信号来告知更新数据不包含更新的数据ID如果包含业务信息就需要考虑更多的幂等和消息丢失等问题消费者获取信号后先批量查询待更新的主数据然后批量更新查询数据更新完成后将查询数据的主数据标识 NeedUpdateQueryData 更新为 false若存在多个消费者同时有迁移动作的情况就涉及并发性问题这与前一场景冷热分离中的并发性处理逻辑类似这里不再赘述消息的时序性问题生产者1 将数据A修改为A1发送消息Q1生产者2 将数据A1修改为A2发送消息Q2消费者1 收到Q1查询数据为A1此时消费者2收到Q2将数据A2迁移到缓存A1迁移到缓存即消费者查询数据库数据后在未迁移数据时被后触发的消费者线程更新了迁移了更新的数据而后先消费的消费者会将后消费消费者的迁移更新掉导致缓存本该后迁移记录丢失。解决方法消费者查询 NeedUpdateQueryDatatrue 数据的同时查询 lastUpdateTime 作为乐观锁字段进行更新。2.3 查询数据如何存储常用的两个中间件是 MongoDB 和 ES选择取决于团队成员的技术结构。我们团队选择的是 ES。特性维度 MongoDB Elasticsearch数据模型 文档型数据库类似JSON结构灵活 搜索引擎擅长处理非结构化文本数据核心优势 高性能读写、灵活的数据模型、横向扩展 强大的全文检索、复杂查询和数据分析查询场景 适合精确查询、范围查询、事务和聚合操作 适合模糊匹配、全文搜索、多条件复杂检索写入性能 写入速度较快支持高并发写入 写入吞吐量通常低于MongoDB但近实时搜索秒级读取性能 精确查询和聚合操作性能优秀 复杂搜索和全文检索性能卓越事务支持 支持多文档ACID事务 不支持事务保证最终一致性资源消耗 磁盘占用通常更小高压缩存储引擎 磁盘和内存消耗相对较高扩展性 支持分片集群需手动配置 天生分布式开箱即用自动分片管理维护 集群配置相对复杂需要专业知识 管理相对简单有完善的监控工具适用场景 Web应用后端、用户画像、设备监控 搜索引擎、日志分析、实时监控不适用场景 复杂的全文搜索需求 需要强事务一致性的场景学习成本 中等查询语法相对简单 较高查询DSL较复杂社区生态 成熟稳定社区活跃 生态丰富插件众多成本考量 通常存储成本更低 资源消耗大总体成本可能更高2.4 查询数据如何使用ES自带查询API在业务代码中直接调用ES即可。这里涉及到一个场景缓存和数据库数据不一致的问题。两种解决思路在查询数据更新到最新前不允许用户查询在数据同步完成前强制查询走主数据源如MySQL而不是ES给用户提示当前数据为2s前的数据如发现数据不准确可尝试刷新通常用户都能接受2.5 历史数据迁移当前方案中只需要把所有历史数据加上标识 NeedUpdateQueryDatatrue程序就会自动处理。2.6 MQES 整体方案业务数据修改后触发异步线程数据同步触发异步方式使用MQ解耦、削峰查询数据到ES适合大数据量的复杂查询查询数据同步到ES会有一定延时用户可能查询到旧数据需给用户提示历史数据迁移只需把所有历史数据的标识改成true系统会自动批量同步到ES整体方案示意图图2-7: MQES整体架构方案示意图这个整体方案看似简单但有一些陷阱必须注意。下面着重介绍使用Elasticsearch时的注意事项。3. ElasticSearch注意事项Elasticsearch的使用要点如何使用Elasticsearch设计表结构Elasticsearch的存储结构Elasticsearch如何修改表结构Elasticsearch的准实时性Elasticsearch可能丢数据Elasticsearch分页3.1 如何使用Elasticsearch设计表结构Elasticsearch基于索引设计无法像MySQL那样使用join查询所以查询数据时需要把每条主数据及关联子表的数据全部整合在一条记录中。下面以常见的订单业务类讲解如何设计ES表结构订单数据结构图3-1: 订单业务数据结构示意图虽然订单数据在关系型数据库中涉及多表但使用Elasticsearch存储数据时不会设计多个表而是将所有表的相关字段数据汇集在一个Document中即一个完整的文档结构{order_ID: o2020103115214521,order_invoice: {},user: {user_ID: U1099,user_name: YiHuiComeOn},order_product_item: [{product_name: 乒乓球拍,product_count: 1,product_price: 149},{product_name: 纸巾,product_count: 2,product_price: 1.4}],total_amount: 20}习惯关系型数据库的同学可能会有疑惑为什么汇聚到同一document中为什么ES不需要关联查询这就涉及到ES特殊的存储结构。3.2 Elasticsearch的存储结构3.2.1 Lucene和MySQL的概念对照Lucene是一个索引系统此处把Lucene与MySQL的一些概念做简单对照Lucene与MySQL概念对照图3-2: Lucene与MySQL概念对照表3.2.2 无结构文档的倒排索引假设有一些无结构文档数据无结构文档图3-3: 无结构文档示例简单倒排索引后的结果简单倒排索引结果图3-4: 无结构文档倒排索引结果无结构的文档经过简单的倒排索引后字典表主要存放关键字而倒排表存放该关键字所在的文档ID。业务数据通常不是无结构的文档内容而是有结构的数据此时如何倒排索引呢3.2.3 有结构文档的倒排索引更复杂的例子每个Doc都有多个FieldField有不同的值包含不同的TermTerm是经过文本分析处理后不可再分割的最小单位。有结构文档示例图3-5: 有结构文档示例倒排表性别倒排索引性别倒排索引图3-6: 性别字段倒排索引示例年龄倒排索引年龄倒排索引图3-7: 年龄字段倒排索引示例武功倒排索引武功倒排索引图3-8: 武功字段倒排索引示例由此可见有结构的文档经过倒排索引后字段中的每个值都是一个关键字存放在Term Dictionary中且每个关键字都有对应地址指向所在文档。3.2.4 ES的Document如何定义结构和字段格式设计ES的Document结构时不需要像MySQL那样关联表而是把所有相关数据汇集在一个Document中。直接将3.1节中订单的JSON文档转成一个ES文档SQL中的子表数据在Elasticsearch中以嵌入式对象格式存储{mappings: {doc: {properties: {order_ID: {type: text},order_invoice: {type: nested},order_product_item: {type: nested,properties: {product_name: {type: text}}},total_amount: {type: long},user: {properties: {user_ID: {type: text},user_name: {type: text}}}}}}}至此大家已经了解了Elasticsearch表结构的设计。在实际业务中主数据修改表结构时ES也要求修改文档结构这时该怎么办3.3 Elasticsearch如何修改表结构ES支持直接添加新字段因为修改字段的类型会导致索引失效所以ES不支持修改原字段类型Elasticsearch底层基于LuceneLucene的倒排索引一旦创建就是不可变的。就像印刷好的书籍你不能直接修改某一页的排版只能重新印刷一本。如果想修改字段的映射表结构需要新建一个索引然后使用Elasticsearch的reindex功能将旧索引复制到新索引中POST /_reindex{source: {index: products_old},dest: {index: products_new}}reindex功能会使旧索引失效直接重命名字段时可以使用alias索引功能。注意通常不会直接删除旧字段常用做法是新版本项目代码兼容旧数据在项目稳定运行后再考虑清理旧字段。3.4 陷阱一Elasticsearch是准实时的吗当更新数据至Elasticsearch且返回成功提示时通过Elasticsearch查询返回的数据可能不是最新的。这个过程涉及Elasticsearch的Shard分片以及Lucene Index、Segment、Document三者之间的关系。Elasticsearch的一个Shard就是一个Lucene Index每一个Lucene Index由多个Segment构成。分片Shard结构图分片结构图图3-9: Elasticsearch分片结构示意图Index、Segment、Document三者之间的关系三者关系图图3-10: Index、Segment、Document关系图数据索引的过程详解当新的Document被创建时数据首先会存放到新的Segment中同时旧Document会被删除并在原来的Segment上标记删除标识。当Document被更新时旧版Document会被标识为删除并将新版Document存放在新的Segment中Shard收到写请求时请求会被写入Translog中然后Document被存放在Memory Buffer中写请求处理图3-11: Elasticsearch写请求处理流程注意Memory Buffer 不会被查询到每隔1秒默认设置Refresh操作被执行一次Memory Buffer中的数据会被写入一个Segment并存放在File System Cache中这时新数据就可以被搜索到了Refresh操作示意图图3-12: Refresh操作数据刷新流程通俗理解整个过程名词解释DocumentES中的基本数据单元相当于一条记录SegmentLucene索引的基本单元是不可变的Memory Buffer临时存储新文档的内存区域Translog记录所有写操作的日志文件Refresh将内存中的数据写入新Segment并使其可搜索的操作File System Cache操作系统级别的磁盘缓存流程解释新数据到达先登记到Translog再放到Memory Buffer定期刷新每1秒将Memory Buffer中的数据写入Segment放到File System Cache此时数据可被搜索通过以上数据索引过程的说明可以发现Elasticsearch并不是实时的而是有1秒延时。解决方案是提示用户查询的数据会有一定延时。3.5 陷阱二Elasticsearch宕机恢复后数据丢失上一小节中提及每隔1秒Memory Buffer中数据会被刷到Segment中此时数据可被用户搜索到但没有持久化一旦系统宕机数据就会丢失。如何防止数据丢失使用Lucene中的Commit操作解决这个问题。Commit操作方法先将多个Segment合并保存到磁盘中再进行持久化标记。但commit有两个问题会占用IO资源使得commit期间数据查询变慢无法解决数据保存时在translog写完还未写入文件系统缓存情况的数据丢失translog持久化到磁盘需要执行fsync操作具体实现方法有两种将index.translog.durability设置成request缺点是耗费资源性能差一些将index.translog.durability设置为async每隔index.translog.sync_interval时间执行一次fsync配置建议# 方案A金融级安全不能丢任何数据PUT /my_index/_settings{index.translog.durability: request}# 方案B普通业务可容忍少量数据丢失PUT /my_index/_settings{index.translog.durability: async,index.translog.sync_interval: 5s}实践总结根据业务需求选择策略业务类型 推荐配置 解释金融交易 durability: request 数据绝对不能丢失电商订单 durability: async, sync_interval: 1s 可容忍极短时间延迟日志分析 durability: async, sync_interval: 5s 丢几条日志没关系记住没有完美的方案只有适合你业务需求的方案3.6 陷阱三分页越深查询效率越低Elasticsearch的读操作流程主要分为两个阶段Query Phase、Fetch Phase。Query Phase协调节点先把请求分发到所有分片每个分片在本地查询后建一个结果集队列将Document ID以及搜索分数存放在队列中再返回给协调节点协调节点建全局队列归并所有结果集并进行全局排序Tips在Elasticsearch查询过程中如果search方法带有from和size参数Elasticsearch集群需要给协调节点返回分片数×fromsize条数据然后在单机上进行排序最后给客户端返回size大小的数据。比如客户端请求10条数据有3个分片那么每个分片会返回10条数据协调节点最后会归并30条数据但最终只返回10条数据给客户端。Elasticsearch读操作示意图图3-13: Elasticsearch读操作两阶段流程Fetch Phase协调节点先根据结果集里的Document ID向所有分片获取完整的Document然后所有分片返回完整的Document给协调节点最后协调节点将结果返回给客户端比如有5个分片需要查询排序序号从10000到10010from10000size10的结果每个分片返回给协调节点计算的数据量是10010条。这是为了防止其他分片中没有数据考虑最坏情况10010条数据都在自己分片上进而把10010条数据全部给协调节点去聚合计算。也就是说协调节点需要在内存中计算10010×550050条记录所以用户分页越深查询速度会越慢分页并不是越多越好。那如何更好地解决Elasticsearch分页问题呢为了控制性能可以使用Elasticsearch中的max_result_window进行配置这个数据默认为10000当fromsize max_result_window时Elasticsearch将返回错误。如果用户确实有深度翻页的需求使用Elasticsearch中search_after的功能也能解决只是无法实现跳页这样分片可以利用游标条件过滤部分数据从而减少数据计算的数量提升查询速度。举例查询结果按照订单总金额分页上一页最后一个订单的总金额total_amount是10那么下一页的查询示例代码如下{query: {bool: {must: [{term: {user.user_name.keyword: YiHuiComeOn}}],must_not: [],should: []}},from: 0,size: 2,search_after: [10],sort: [{total_amount: asc}],aggs: {}}至此Elasticsearch的一些要点就介绍完了。MQ也有一些要点比如确保时序、确保重试、确保消息重复消费不会影响业务以及确保消息不丢失等后续各章节会有相应的场景描述这里就不再展开了。4. 小结查询分离这个解决方案虽然能解决一些问题但也要认识到它的不足使用Elasticsearch存储查询数据时要接受一些局限性有一定延时深度分页不能自由跳页有丢数据的可能性主数据量越来越大后写操作还是慢到时还是会出问题。比如工单数据虽然已经去掉所有外键但当数据量上亿时插入还是会有问题