当当网打开速度慢是啥原因

一、网络最小带宽

这是最主要的要素，在慢的网站放在好的带宽下拜访速度相同快，网络的带宽包含对网站地点服务器带宽和用户端两个方位，对接点指的是出口端与进口端(如电信对网通的对接点)。

二、DNS解析时刻

DNS解析包含往复解析的次数及每次解析所花费的时刻，它们两者的积即是DNS解析所耗费的时刻，因而，许多人无视了DNS的疑问，其实，DNS对网站解析速度也是十分重要的。

三、机器的装备

包含服务器端与客户机端的硬件装备程度，相同的网络环境下，双核的服务器的运算才干必定要强一些，毫无疑问的，相同的网络环境下，你用一台赛扬的机器和奔四双核处置器的电脑，翻开相同的页面，速度，也必定不相同。

四、服务器软件

软件多少、安稳和软件的正确装备，都会影响到服务器环境，致使影响到网络速度。服务器装置软件防火墙，会献身一些网络速度，所以VPS、或独立服务器用户装一个防火墙足矣。

五、页面内容的巨细（重要）

页面文件的巨细是网站是否能疾速翻开最重要一个要素，若是说服务器等硬件方面咱们决议不了，我强烈主张从这儿下手，不管是表格仍是DIV+CSS，恰当的优化代码，都能削减页面巨细。

尽量优化代码，用最少的代码，冗余代码也是拖慢网站速度之一。

六、许多数据库 *** 作

小网站在履行许多数据库 *** 作时，也会影响网站翻开速度，这儿使asp+access布局的网站尤为显着，尤其是一起有许多用户提交谈论时，就 *** 作数据库锁死，致使网站打不开。

七、用许多javascript

网站上运用许多JS是大忌，不只搜索引擎无法录入，一起会不断提交恳求添加服务器担负，例如鼠标特效、节目的特效、状态栏的特效等等。这些特效的原理是先由服务器下载到你本地的机器，然后在你本地机器上运转发生，然后你才干看到的。特效做的多了，在你本地机器上就要运转大半天才干悉数完结，而若是你的主机装备通常的话，那就更慢了。所以成都网站建造主张一定要少用javascript特效。

八、页面上用大图像和FLASH

咱们晓得图像是拖慢网速最重要一个要素，图像通过处置，可以使图像空间变小，不然许多的图像一开始都会占用许多空间又使网站翻开速度变得很慢，相同FLASH也是一个道理。

九、过多引证了其他网站的内容

包含你引证其他网站的图像、视频文件等，若是直接在页面引证另外网站的东西，而那个网站的速度又慢，或许那个网站的该页面现已不存在了，那么你翻开的速度就会十分慢 。

第一点：用户体验。

我觉得这是SEO里的重点，因为如果一个用户体验都不良好的网站，搜索引擎也不会认为你是一个好的网站，搜索引擎的排名算法有很大程度的去考虑用户体验的。所以我们建设一个网站要让用户访问到我们的网站中能够很清楚的自己在什么地方，接下来要去什么地方，很方便的点击链接，得到他想要得到的信息。假如你进一个网站，网站内部混乱不堪，没有清晰的导航，没有你像看到的信息锚文字，你是是不是也会不假思索的关闭这个网站，去寻找另一个网站。

第二点：收录量。

我们进行网站结构优化的目的就是利于SEO，SEO的最基础前提是你的网站有收录，如果一个良好的网站结构，搜索引擎蜘蛛也很容易爬行到你的网站内页对你的网站进行收录，像我的tuihongbaocn这个网站网站结构就是很清晰的，虽然收录量不是很(尴)大(尬)。

第三点：网站权重的分配。

网站的哪些内容是你最想给用户展现的，哪些内容是比较次要的，那么这个在网站结构规划的时候，就要对网站进行权重分配，权重高的网站自然排名就会比较高。这样才能突出我们的主要业务。

第四点：锚文字。

要说网站的站外锚文字自己控制不了，那么在站内，锚文字站长都是可以控制的。为什么要达到锚文字清晰的目的，因为锚文字是搜索引擎排名中很重要的一部分。

关于当当网架构优化的几点心得

第一，对技术部组织架构进行调整。

将原来的职能化组织中的产品、研发和测试部门按照产品线进行整合，转型为Unit化，以加强同一产品线不同职能团队之间的配合协作，沟通更高效，团队更为聚焦。

这样的组织结构更易于应用敏捷，与实施敏捷的前提同理，产品线拆分建立在系统架构解耦基础之上，在这一点上，系统架构与组织架构异曲同工且相辅相成。解耦越充分，系统边界越清晰，模块越小，越适合敏捷团队，能够快速响应业务需求。

业务相近的产品线组成一个产品研发部，这样多数的小型需求在部门内就可以解决，面对紧急项目还可以灵活使用人力资源，并为员工创造接触更多类型业务需求的机会。

第二，系统分层依赖。

随着业务逻辑越来越复杂，系统越来越多，相互依赖也越来越多。比如我的当当中就聚合了安全中心、用户、账户、订单、收藏夹、推荐等多维度的信息，需要调用多个系统服务。经过讨论，决定将用户交互层面的前端页面与原有的后端系统拆分，并入前端的产品线，以便为用户提供更好的服务。

而后端系统之间的依赖关系也需要更为精细的分层定义，对于促销系统，需要会员系统、订单系统、价格系统提供基础数据;对于运费系统需要商品信息和配货数据，而在精准定位销售区域的前提下，库存只是配货的基础数据，配货系统负责判断是否有货，Promise则根据配货结果计算预计送达时间。

调整系统之间的关系是很难的，牵一发而动全身，但重构是契机，2015年，对于电商的核心系统交易和促销进行了重构，同时价格、配货、运费等系统也进行了较大调整，从而使系统间依赖问题得到了明显改善。

第三，服务化。

微服务为互联网行业的服务化指明了方向，也坚定了我们进行服务拆分和解耦的决心。

原有的架构以系统为维度，服务归属于明确的系统，而系统的划分一般以业务功能为聚合，随着业务的发展，新的业务功能层出不穷，总会有一些打破原有的系统边界，给架构提出难题。

服务化，不仅是指系统将能力通过服务对外提供，更重要的是服务本身就是承载业务功能的单元，如果有组合了多个逻辑难以归入某系统的服务，不必纠结，作为独立的业务模块开发就是了，以服务为单元，系统架构更加扁平，简单清晰。

微服务架构中，服务粒度会更小，服务治理的需求更加迫切，更需要技术手段解决，比如分布式服务框架，当当使用的是基于Dubbo二次研发的DubboX，以及结合ddframe实现的服务调用监控。

去年的容器技术爆发，为微服务架构实施提供了有力工具，当当内部也在部分系统使用了Docker。

微服务大势所趋，秉承SOA理念，在服务治理中心的基础上，将系统弱化，提供更多的基础服务，提高了系统的复用性和灵活性。

第四，平台化。

平台化包括两个维度，技术平台化和系统平台化。

技术平台化是指在技术层面建立统一的体系，包括根据行业特点进行技术选型，使用稳定可靠的技术组件。

当当从2012年开始将原有的net平台向Java平台迁移，从封闭到开源，应用电商行业的主流技术栈，到2015年，基本完成了技术转型，主要后端业务系统都转移到Java平台。

经过数年的积累，2015年当当架构部研发了Java应用开发框架ddframe，目的是分离技术和业务，封装技术细节，将应用开发人员的精力集中在业务开发上。

随后再接再厉，当当架构部又推出了用来替代TBSchedule的分布式作业调度框架Elastic-Job。并将之开源，基于JDBC的分布式数据库中间件Sharding-JDBC也在开发中。

统一的技术栈，能够复用技术资源，持续积累整体的研发能力，为做精做专提供更好的基础条件。

系统平台化是指搭建基础平台，包括测试平台、分布式服务平台、自动化运维平台、监控平台、缓存集群、消息中间件平台、大数据处理平台、项目管理系统、日志平台、问题跟踪系统等。

基础平台是各业务系统有机协作的基础，保证了整个技术架构的全面可控，能够降低系统运维复杂度，是大型电商系统不可或缺的组成部分，良好的基础平台是技术实力和管理能力的双重体现，而多数公司更注重业务，会在基础平台建设方面欠下许多技术债务。

2015年，当当搭建了自动化运维平台Pangu、监控平台Radar，重构了项目管理系统，Redis集群管理平台也在搭建中。

第五，核心系统重构。

在电商业务发展的快节奏之下，核心系统持续迭代是常态，而且基本两、三年以上，就需要考虑重构，否则难以支撑业务的快速变化。

另外，系统重构集中梳理业务逻辑和系统依赖，整理统一的文档，剔除无用功能，归并多个版本，甩掉历史包袱重新设计架构，适度的前瞻性设计使系统在一定周期内具备业务扩展性。

2015年，当当完成了交易系统和促销系统进行了重构。

交易系统在2015年10月底完成新老版本切换。重构耗费约1500人天，重构代码17万行，全部切换至Java开源技术架构，为公司节约大量成本，并进行了架构优化，整体性能平均提升25%，经受住了双十一和双十二的考验。

在当当，有一些“类促销”业务，从广义上可以归入促销范畴，但业务与数据均不属于促销系统，在促销系统重构设计中，我们考虑将这类业务逐渐回收;另外，促销系统能不能承担一些营销的功能带着这两点考虑，在促销基础上进一步抽象出活动模型。

Twitter-Snowflake算法产生的背景相当简单，为了满足Twitter每秒上万条消息的请求，每条消息都必须分配一条唯一的id，这些id还需要一些大致的顺序（方便客户端排序），并且在分布式系统中不同机器产生的id必须不同。各种主键ID生成策略对比，见 常见分布式主键ID生成策略

把 41位的时间前缀 ， 10位的节点标识 ， 12位的sequence 组合在一起。

除了最高位bit标记为不可用以外，其余三组bit占位均可浮动，看具体的业务需求而定。 默认情况下41bit的时间戳，1970年算起可以支持该算法使用到2038年，10bit的工作机器id可以支持1024台机器，序列号支持1毫秒产生4096个自增序列id 。

Snowflake是Twitter在2010年用Scala语言写的一套主键生成策略，用Thrift对外发布主键生成服务，其中依赖了Twitter内部的Infrastructure，后来Twitter用 Twitter-server 代替了Snowflake，自2012年起就未更新。见 Twitter-Snowflake项目地址（Tags:snowflake-2010）

之前写了一个Java的实现，改自网上一个版本: Twitter的分布式自增ID算法Snowflake实现分析及其Java、Php和Python版 。后来看到当当网的 Sharding-JDBC 分库分表中间件已实现了此算法。就直接在其中添加了一些新特性，已merge。( 具体实现 , 说明文档 )

添加3种IdGenerator实现。

用笔记本（i7-3632QM 22GHz 四核八线程）测试了下，每秒生成409万（理论上的峰值），CPU占用率185%。

随着时间和业务的发展，数据库中的数据量增长是不可控的，库和表中的数据会越来越大，随之带来的是更高的 磁盘 、 IO 、 系统开销 ，甚至 性能 上的瓶颈，而单台服务器的 资源终究是有限 的。

因此在面对业务扩张过程中，应用程序对数据库系统的 健壮性 ， 安全性 ， 扩展性 提出了更高的要求。

以下，我从数据库架构、选型与落地来让大家入门。

数据库会面临什么样的挑战呢？

业务刚开始我们只用单机数据库就够了，但随着业务增长，数据规模和用户规模上升，这个时候数据库会面临IO瓶颈、存储瓶颈、可用性、安全性问题。

为了解决上述的各种问题，数据库衍生了出不同的架构来解决不同的场景需求。

将数据库的写 *** 作和读 *** 作分离，主库接收写请求，使用多个从库副本负责读请求，从库和主库同步更新数据保持数据一致性，从库可以水平扩展，用于面对读请求的增加。

这个模式也就是常说的读写分离，针对的是小规模数据，而且存在大量读 *** 作的场景。

因为主从的数据是相同的，一旦主库宕机的时候，从库可以 切换为主库提供写入 ，所以这个架构也可以提高数据库系统的 安全性 和 可用性 ；

优点：

缺点：

在数据库遇到 IO瓶颈 过程中，如果IO集中在某一块的业务中，这个时候可以考虑的就是垂直分库，将热点业务拆分出去，避免由 热点业务 的 密集IO请求 影响了其他正常业务，所以垂直分库也叫 业务分库 。

优点：

缺点：

在数据库遇到存储瓶颈的时候，由于数据量过大造成索引性能下降。

这个时候可以考虑将数据做水平拆分，针对数据量巨大的单张表，按照某种规则，切分到多张表里面去。

但是这些表还是在同一个库中，所以库级别的数据库 *** 作还是有IO瓶颈（单个服务器的IO有上限）。

所以水平分表主要还是针对 数据量较大 ，整体业务 请求量较低 的场景。

优点：

缺点：

四、分库分表

在数据库遇到存储瓶颈和IO瓶颈的时候，数据量过大造成索引性能下降，加上同一时间需要处理大规模的业务请求，这个时候单库的IO上限会限制处理效率。

所以需要将单张表的数据切分到多个服务器上去，每个服务器具有相应的库与表，只是表中数据集合不同。

分库分表能够有效地缓解单机和单库的 性能瓶颈和压力 ，突破IO、连接数、硬件资源等的瓶颈。

优点：

缺点：

注：分库还是分表核心关键是有没有IO瓶颈 。

分片方式都有什么呢？

RANGE（范围分片）

将业务表中的某个 关键字段排序 后，按照顺序从0到10000一个表，10001到20000一个表。最常见的就是 按照时间切分 （月表、年表）。

比如将6个月前，甚至一年前的数据切出去放到另外的一张表，因为随着时间流逝，这些表的数据被查询的概率变小，银行的交易记录多数是采用这种方式。

优点：

缺点：

HASH（哈希分片）

将订单作为主表，然后将其相关的业务表作为附表，取用户id然后 hash取模 ，分配到不同的数据表或者数据库上。

优点：

缺点：

讲到这里，我们已经知道数据库有哪些架构，解决的是哪些问题，因此， 我们在日常设计中需要根据数据的特点，数据的倾向性，数据的安全性等来选择不同的架构 。

那么，我们应该如何选择数据库架构呢？

虽然把上面的架构全部组合在一起可以形成一个强大的高可用，高负载的数据库系统，但是架构选择合适才是最重要的。

混合架构虽然能够解决所有的场景的问题，但是也会面临更多的挑战，你以为的完美架构，背后其实有着更多的坑。

1、对事务支持

分库分表后（无论是垂直还是水平拆分），就成了分布式事务了，如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价（XA事务）；如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担（TCC、SAGA）。

2、多库结果集合并 （group by，order by）

由于数据分布于不同的数据库中，无法直接对其做分页、分组、排序等 *** 作，一般应对这种多库结果集合并的查询业务都需要采用数据清洗、同步等其他手段处理（TIDB、KUDU等）。

3、数据延迟

主从架构下的多副本机制和水平分库后的聚合库都会存在主数据和副本数据之间的延迟问题。

4、跨库join

分库分表后表之间的关联 *** 作将受到限制，我们无法join位于不同分库的表（垂直），也无法join分表粒度不同的表（水平）， 结果原本一次查询就能够完成的业务，可能需要多次查询才能完成。

5、分片扩容

水平分片之后，一旦需要做扩容时。需要将对应的数据做一次迁移，成本代价都极高的。

6、ID生成

分库分表后由于数据库独立，原有的基于数据库自增ID将无法再使用，这个时候需要采用其他外部的ID生成方案。

一、应用层依赖类（JDBC）

这类分库分表中间件的特点就是和应用强耦合，需要应用显示依赖相应的jar包（以Java为例），比如知名的TDDL、当当开源的 sharding-jdbc 、蘑菇街的TSharding等。

此类中间件的基本思路就是重新实现JDBC的API，通过重新实现 DataSource 、 PrepareStatement 等 *** 作数据库的接口，让应用层在 基本 不改变业务代码的情况下透明地实现分库分表的能力。

中间件给上层应用提供熟悉的JDBC API，内部通过 sql解析 、 sql重写 、 sql路由 等一系列的准备工作获取真正可执行的sql，然后底层再按照传统的方法（比如数据库连接池）获取物理连接来执行sql，最后把数据 结果合并 处理成ResultSet返回给应用层。

优点

缺点

二、中间层代理类（Proxy）

这类分库分表中间件的核心原理是在应用和数据库的连接之间搭起一个 代理层 ，上层应用以 标准的MySQL协议 来连接代理层，然后代理层负责 转发请求 到底层的MySQL物理实例，这种方式对应用只有一个要求，就是只要用MySQL协议来通信即可。

所以用MySQL Navicat这种纯的客户端都可以直接连接你的分布式数据库，自然也天然 支持所有的编程语言 。

在技术实现上除了和应用层依赖类中间件基本相似外，代理类的分库分表产品必须实现标准的MySQL协议，某种意义上讲数据库代理层转发的就是MySQL协议请求，就像Nginx转发的是>

以上就是关于当当网打开速度慢是啥原因全部的内容，包括:当当网打开速度慢是啥原因、网站结构该怎么去优化 关于当当网架构优化的几点心得、数据库分库分表（二）Twitter-Snowflake（64位分布式ID算法）分析与JAVA实现等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！