企业官网建设流程全解析

外贸网站建设团队,mvc网站开发实例,淄博英文网站建设,湖南网站建设公司 尖端磐石网络#x1f449; 这是一个或许对你有用的社群 #x1f431; 一对一交流/面试小册/简历优化/求职解惑#xff0c;欢迎加入「芋道快速开发平台」知识星球。下面是星球提供的部分资料#xff1a; 《项目实战#xff08;视频#xff09;》#xff1a;从书中学#xff0c;往事…这是一个或许对你有用的社群 一对一交流/面试小册/简历优化/求职解惑欢迎加入「芋道快速开发平台」知识星球。下面是星球提供的部分资料《项目实战视频》从书中学往事上“练”《互联网高频面试题》面朝简历学习春暖花开《架构 x 系统设计》摧枯拉朽掌控面试高频场景题《精进 Java 学习指南》系统学习互联网主流技术栈《必读 Java 源码专栏》知其然知其所以然这是一个或许对你有用的开源项目国产Star破10w的开源项目前端包括管理后台、微信小程序后端支持单体、微服务架构RBAC权限、数据权限、SaaS多租户、商城、支付、工作流、大屏报表、ERP、CRM、AI大模型、IoT物联网等功能多模块https://gitee.com/zhijiantianya/ruoyi-vue-pro微服务https://gitee.com/zhijiantianya/yudao-cloud视频教程https://doc.iocoder.cn【国内首批】支持 JDK17/21SpringBoot3、JDK8/11Spring Boot2双版本来源juejin.cn/post/7359467967019139108一、需求背景二、业务现状三、技术选型四、唯一ID方案五、分片键和分片策略选择六、最佳实践七、风险评估与应对措施八、常见问题及解决方案九、总结十、参考资料一、需求背景随着公司业务的发展订单系统的数据量和访问量日益增长单库单表的架构已经无法满足我们的需求。主要面临以下问题数据量大单一数据库存储所有订单数据导致数据量过大影响查询效率。并发压力大大量用户同时访问系统产生高并发请求对数据库造成较大压力。扩展性差当需要对订单表进行改动时大量的数据造成表结构修改时间变长。基于 Spring Boot MyBatis Plus Vue Element 实现的后台管理系统 用户小程序支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能项目地址https://github.com/YunaiV/ruoyi-vue-pro视频教程https://doc.iocoder.cn/video/二、业务现状订单系统目前面临以下几个关键问题及相应的解决思路问题类型当前状况解决方案主键设计问题订单表有主键orderId和唯一索引orderNoorderId依赖数据库自增orderNo自定义生成并且后4位为类用户id内部场景用orderId进行数据传递外部场景用orderNo进行数据传递。去除数据库自增将orderId和orderNo进行合并将自定义编号作为唯一主键内外部场景全部采用orderNo进行数据传递。索引过多订单表超过10个索引部分索引用于C端场景部分索引用于B端场景。将OLTP中的订单数据同步到OLAP数据库中确保所有C端场景能够命中分库分表的分片键将B端分析场景进行剥离例如查询订单列表在OLAP数据库中进行查询再根据订单主键CRUD时再走OLTP数据库。历史数据不规范订单表中存在部分老数据老orderNo没有采用后4位是类用户id并且老orderNo中可能存在字母。借助Flink将老订单编号数据进行清洗数据清洗技术方案另行商议统一采用现有订单编号规则。关联表设计不一致订单表存在一些拓展表比如订单位置、订单申诉记录等有些采用orderNo进行关联有些采用orderId进行关联。统一采用主键进行关联并且需要保证关联字段为分片键。如果有分库最好将拓展表也进行分库分表并且需要保证拓展表的分库分表规则和原表一致。表结构冗余订单表中字段过多有计费、开票、退款等非核心数据。考虑纵向拆分可以从以下几个方面考虑是否核心、更新是否频繁、字段长度是否过大。基于 Spring Cloud Alibaba Gateway Nacos RocketMQ Vue Element 实现的后台管理系统 用户小程序支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能项目地址https://github.com/YunaiV/yudao-cloud视频教程https://doc.iocoder.cn/video/三、技术选型1. 分库分表和分布式数据库对比理解不同类型数据库的特点普通数据库通常采用传统的垂直架构由单一的数据库服务器提供数据存储和查询服务。分布式数据库采用水平分片的方式将数据分散到多个数据库服务器上实现数据的高可用性和可扩展性。云原生数据库基于云计算技术构建具有容器化、微服务等特性可以快速部署和扩展。云原生分布式数据库结合了分布式数据库和云原生数据库的特点实现高性能、高可用、可扩展的数据库服务。产品名称PolarDB-分区表OceanBasePolarDB-XTIDB传统分库分表开发团队阿里-阿里云团队阿里-蚂蚁团队阿里-阿里云团队PingCAP团队根据具体实现和需求可能有多个开发团队参与类型云原生数据库分布式数据库云原生分布式数据库分布式数据库传统数据库应用场景HTAP行列混合HTAP行列混合OLTP行存索引HTAP行列混合OLTP行存产品优势一写多读、共享分布式存储、计算与存储分离、自动读写分离、高速链路互联、数据可靠性和强一致性、维护成本很低、支持列存索引可满足金融级容灾标准、水平扩展、支持多租户资源隔离、支持列存索引、支持空间索引支持数据强一致性、支持水平扩展、列存索引灰度中水平扩展、实时HTAP、行列混合灵活性强、不需要进行数据库迁移产品劣势分区算法只能采用单一key、行存节点进行了分区列存节点也会分区、分区表不支持空间类型成本比PolarDB贵一倍、涉及到数据库迁移成本较高、涉及到数据库迁移、列存索引还在灰度中、OLAP依赖并行计算、目前不支持mysql8.0不属于阿里云体系、运维成本较高、涉及到数据库迁移、不支持空间类型考虑分布式事务兼容性、需要集成中间件分片原理推荐使用分区表代替分库分表基于分布式技术的分片、无共享架构实现数据的分散存储和处理。基于MySQL内核的分片、通过特定的存储计算分离架构实现数据的分散存储和处理。基于TiKV内核的分片、通过Raft协议实现数据的一致性复制和分散存储。根据业务需求和自定义的分片规则进行数据分散存储和处理;可以根据具体的实现方式采用不同的分片算法和策略。适用场景单一分片键场景、需要HTAP能力、对维护成本敏感金融级应用、多租户场景、需要高可用和强一致性大型OLTP系统、需要水平扩展、对一致性要求高需要HTAP能力、开源社区活跃、需要水平扩展成本敏感、技术栈固定、需要灵活配置文档地址PolarDBOceanBasePolarDB-XTIDBShardingSphere2. 分库分表方案对比中间件名称ShardingSphere-JDBCShardingSphere-ProxyMycat类型客户端分表数据库代理数据库代理开发团队ApacheApacheMycat社区优势轻量级、易于集成、支持多种数据源、提供分布式事务和读写分离功能功能丰富、支持多种数据源、提供分布式事务、读写分离、分布式主键生成等功能、业务无侵入、支持异构语言开源免费、功能完善、支持多种数据源、提供分布式事务、读写分离、分布式序列等功能、适用于各种项目劣势代码改造、集成分布式事务困难、配置较为繁琐性能损耗略高、需要单独部署维护社区支持有限、维护和更新不及时、性能损耗略高、需要单独部署维护适用场景对性能要求较高代码侵入性可接受的OLTP应用支持异构语言独立于应用程序部署适用于OLAP应用以及对分片数据库进行管理和运维的场景开源免费适用于中小规模项目或预算有限的场景总结适用于对性能要求较高代码侵入性可接受的OLTP应用支持异构语言独立于应用程序部署适用于OLAP应用以及对分片数据库进行管理和运维的场景开源免费但社区支持有限、维护和更新不及时。独立于应用程序部署适用于OLAP应用以及对分片数据库进行管理和运维的场景四、唯一ID方案在分库分表环境中设计合适的唯一ID生成方案至关重要。以下是几种常见方案的比较1. 数据库自增或Redis自增优点实现简单易于理解缺点单点风险、单机性能瓶颈、会暴露业务量适用场景小规模系统数据量不大且增长缓慢的场景2. Snowflake算法组成部分1位符号位始终为041位时间戳精确到毫秒可使用69年10位工作机器ID可支持1024个节点12位序列号同一毫秒内可生成4096个ID特点分析优点高性能高可用、易扩展、ID有序缺点需要独立中心节点时钟回拨可能造成ID重复、没有业务标识适用场景高并发分布式系统每秒生成数万ID的场景3. UUID/随机算法优点简单、无需中心化节点缺点生成ID较长有极小重复几率不利于索引性能适用场景对ID长度不敏感且对性能要求不高的系统4. 美团分布式ID生成-Leaf实现方式Leaf-snowflake通过集群部署自动剔除时钟回拨的节点避免ID重复Leaf-segment在数据库自增基础上改进加入批量生成和本地缓存机制特点分析优点高可用、解决自增和Snowflake部分缺点缺点弱依赖ZooKeeper需要独立部署Leaf系统适用场景大型分布式系统对ID生成有高可用要求的场景5. 自定义业务ID示例格式订单类型(1) 业务类型(1) 时间戳yyMMddHHmmss(12) 随机数(4) 类用户id后4位特点分析优点单机生成、含业务属性、含用户标识、有顺序性缺点过万QPS情况下容易出现ID冲突适用场景中小型系统对ID可读性有要求的业务五、分片键和分片策略选择1. 时间范围Range特性说明适用场景数据有明显的时间属性例如日志表、记录表、统计表等优点天然分片好扩展方便范围查询和排序操作也可以方便数据归档缺点数据可能分布不均匀易引起单机负载过大的问题2. 租户IDList特性说明适用场景数据具有明显业务标识例如Saas系统中的表按照租户ID、订单表按照订单类型、工单表按照工单类型优点可以根据具体的属性值进行分片方便根据属性值进行查询和过滤操作缺点分片规则不好维护可能产生数据倾斜数据不好扩容3. 自定义业务IDHash特性说明适用场景常用于互联网C端场景例如根据用户ID分片可以轻松的根据用户ID查找用户所有数据优点数据分布均匀可以实现负载均衡缺点数据扩容困难范围查询效率较低六、最佳实践结合上述技术选型对比并从数据迁移成本、可维护性考虑最终决定采用ShardingSphere-JDBC分库分表方案。1. 改造点梳理1.1 数据库结构改造改造项具体内容订单表合并字段创建新订单表将orderNo和orderId进行合并统一采用自定义编号自定义编号长度会超过long最大值需要采用string类型关联表改造将有orderId字段的相关表进行改造统一通过自定义编号进行关联字段剥离将订单表中多余字段进行剥离待定1.2 代码改造改造项具体内容数据源隔离区分OLTP请求和OLAP请求并从数据源进行隔离引入中间件引入ShardingJDBC并配置分片键、分库分表数据源、分布式事务代理查询优化join查询改造分表后的关联查询必须带有分片键1.3 数据清洗清洗项具体内容订单号清洗对不符合规则的老订单号进行清洗生成新订单号并记录新老订单号关系orderNo关联清洗对有关联orderNo的表进行清洗将老订单号替换成新订单号orderId关联清洗对有关联orderId的表进行改造清洗将orderNo注入到有orderId的关联表中1.4 数据分片数据规模估算现在日订单高峰期20W按照当前业务5倍进行规划并预计10年订单量日订单量100W年订单量3.6亿10年订单量36亿允许单表最大订单量约5000W36亿/5000W 72为了满足一致性hash原则2^n取64张表2. 分布式事务Seata接入参考SpringCloud多数据源接入Seata和ShardingJDBC最佳实践3. 实施步骤步骤具体内容新建库表在新订单库中创建订单主表和分表主要字段包括订单编号、用户ID、订单状态、金额等信息生成新订单号离线生成新订单号并记录新老订单号关系表order_new_relation保存原订单ID、原订单编号和新订单编号Flink数据同步通过Flink将老订单数据与关系表进行关联使用新订单号替换旧数据按照分片规则将数据同步到对应分表同时处理订单拓展表的同步七、风险评估与应对措施风险点可能影响应对措施分片键选择不当查询效率低下数据分布不均1. 充分分析业务查询模式 2. 选择高频查询字段作为分片键 3. 必要时进行双写或异构索引数据迁移风险数据丢失服务中断1. 制定详细的迁移计划并演练 2. 增量同步 全量校验 3. 准备回滚方案分布式事务一致性数据不一致业务异常1. 使用成熟的分布式事务框架 2. 降低分布式事务粒度 3. 实现补偿机制和监控告警查询性能下降用户体验差系统响应慢1. SQL优化避免跨分片查询 2. 合理使用缓存 3. 添加读写分离和索引应用代码改造工作量大开发周期延长引入bug1. 分阶段实施 2. 完善测试用例 3. 采用灰度发布策略八、常见问题及解决方案Q1: 如何处理跨分片的分页查询解决方案使用流式查询避免大offset使用上次查询的最后一条记录ID作为条件对于复杂报表查询建议使用OLAP数据库Q2: 分库分表后如何保证唯一性约束解决方案业务层面进行唯一性校验使用全局唯一ID生成器使用分布式锁进行控制Q3: 如何进行数据扩容解决方案对于Hash分片采用翻倍扩容如64张表扩展到128张表使用一致性Hash算法减少数据迁移提前使用FlinkCDC进行数据实时同步Q4: 分布式事务超时如何处理解决方案设置合理的超时时间Seata有自动补偿机制高并发场景下减少分布式事务的使用减少大事务的使用九、总结本方案结合一段时间内未来业务规模、运维成本、服务器成本等多种因素进行考虑并分析了分区表、分布式数据库、分库分表的区别和优劣势。也简单介绍了一下分库分表需要考虑的唯一ID、分片键、分片算法等问题并结合实际业务简单梳理了一下改造方案。本文采用停机迁移分库分表方案如果想要不停机迁移可以参考大众点评分阶段实施。备注如果只分表不分库也能满足需求的话分区表其实也是一个不错的选择不用引入其它第三方组件mysql就原生支持并且对开发比较友好。但是PolarDB分区表不支持多个分区键用同一个分区规则并且PolarDB列存数据也会按照行存的进行分区有一定的性能损耗。十、参考资料TIDB技术内幕-说存储大众点评订单系统分库分表实践美团-分布式ID生成系统Leaf介绍SpringCloud多数据源接入Seata和ShardingJDBC最佳实践欢迎加入我的知识星球全面提升技术能力。 加入方式“长按”或“扫描”下方二维码噢星球的内容包括项目实战、面试招聘、源码解析、学习路线。文章有帮助的话在看转发吧。 谢谢支持哟 (*^__^*