实操干货:怎么打广告才能吸引人SEO

　　实操干货:怎么打广告才能吸引人SEO

　　精心打磨 为什么选择我们？

　　

　　从技术到实力，我们遥遥领先，不比同行。从过去的优化案例到最新的发明和方向，SEO站长推广相比SEM节省了太多成本，助手方便查询网址优化教程。这是一个容易被忽视和低估的一点是，做好内链也是加速网站收录的方法之一，很容易提升长的排名tail 关键词 如果内部链接做得很好。建站之初需要规划一张巨大的树根状发展图，所有文章相关性都要串联起来。

　　全天在线工单受理

　　

　　选择时空SEO助手，我们把客户放在第一位。7*18小时专业无忧售后服务，分钟快速响应，为您的业务全面保驾护航。

　　分享:精选文章 | TDengine在得物的落地应用

　　TD引擎

　　取得一些东西

　　登陆申请

　　背景

　　德物作为一家互联网电商，有很多系统和场景需要流量监控和保护。因此，我们在深度定制开源流控保护组件 Sentinel() 的时候，增加了很*敏*感*词*来帮助改善各种业务系统的流量。控制保护。

　　在开发过程中，我们发现Sentinel的开源版本不支持流控数据持久化，我们非常需要这样一个功能：我们需要一个能够承载大量流监控数据，并且可以存储和存储的数据库。有效地存储数据。查询。

　　目前在生产环境中，我们有数百个业务系统和数千台服务器连接到 Sentinel，这样产生的流控数据无疑是巨大的。所以对于这个需求，选择一个合适的数据库无疑是极其重要的，一个好的选择可以事半功倍。

　　数据库选择

　　首先粗略估计一下当前数据量的理论上限：

　　目前生产环境有上千个Sentinel资源，Sentinel的监控数据时间粒度以秒计。理论上一天可以产生数亿条数据，理论数据写入速度达到10000TPS，业务还是很快的。随着发展，可以预见数据量会进一步爆发，而这种级别的数据显然无法与传统的关系型数据库一起使用。

　　因为有一些内部应用在使用 TiDB，所以我先看了一下使用 TiDB 的可行性，但很快就放弃了。毕竟作为分布式数据库，它并不是针对监控数据等时序特性强的场景。.

　　排除后，我们将研究重点放在时间序列数据库上。

　　每个主流时间序列数据库都有自己的优缺点：

　　当我准备进一步了解Clickhouse时，我的同事安利创建了一个国内的物联网大数据平台-TDengine。

　　只是在网上了解了一下，发现口碑不错，社区活跃度也很高。后来去官网查看了TDengine和其他数据库的对比报告，发现在性能方面也很不错。

　　于是我们写了一个demo，简单的使用了TDengine。整个过程中，借助清晰的文档，学习成本可以接受，所以我们最终决定使用TDengine。

　　数据结构和

　　造型

　　数据结构

　　首先，我们来看看 Sentinel 的流量数据是如何呈现的。

　　从上图可以看出，左侧是应用列表，每个应用的菜单中都有独立的监控面板。在监控面板中，以资源为粒度统计所有资源的流量数据，如QPS、拒绝等。QPS、响应时间等。

　　所以从前端渲染的角度来看，数据的唯一键应该是application-resource。

　　然后我们从内部实现的角度来看数据的结构。

　　Sentinel 客户端统计每台服务器上所有资源的流量数据，以秒为单位进行聚合，并记录在本地日志中。控制台通过调用客户端暴露的接口获取采集的流量数据，然后在服务维度聚合所有单机的流量数据并存储在内存中。

　　因此，我们需要存储的数据是与应用程序资源一起落入数据库的唯一属性。

　　数据建模

　　

　　TDengine官方文档中建议的数据建模方法如下：

　　"

　　TDengine为了充分利用其数据的时间序列等数据特性，要求每个数据采集点有单独的表。

　　使用一个数据采集point 指向一张表，可以最大程度保证插入和查询单个数据采集point 的最佳性能。

　　在TDengine的设计中，用一张表来表示一个具体的数据采集点，用一张超表来表示一组相同类型的数据采集点。用户在为特定数据采集点创建表时，以超表的定义为模板，指定特定采集点（表）的标签值。与传统的关系型数据库相比，表（一个数据采集 点）是静态标记的，这些标记可以在之后添加、删除和修改。一个超表收录多个具有相同时间序列数据架构但具有不同标签值的表。

　　"

　　可以看出，官方文档中建议的数据建模方式完全符合这个场景的数据特性：一个application-resource就是一张表，所有application-resource都放在一个super table中进行聚合查询。因此，在表结构的设计中，采用了官方文档推荐的方法。

　　另外，在标签的选择上，虽然目前不需要聚合操作，但考虑到未来聚合操作很可能会在应用的维度上进行，我们决定将一些应用信息作为标签记录在表中。

　　整体结构

　　目前的整体架构图如上。每个连接到 Sentinel 的业务系统都会定期向控制台发送心跳请求，以维护机器的健康。

　　控制台定期轮询所有机器，拉取业务系统中Sentinel客户端记录的监控数据，经过聚合处理后批量写入TDengine集群。

　　由于场景简单，不作为主要监控系统，数据目前可接受少量丢失，因此没有设计过多的故障处理机制。

　　技术选型

　　连接器

　　在连接器的选择上，公司的主要开发语言是Java，相关的生态也比较齐全，所以选择JDBC连接器是理所当然的。

　　此外，JDBC 的性能优于 HTTP，并且 JDBC 驱动还支持节点不可用时的自动节点切换。

　　唯一不便的是，JDBC方式会强烈依赖本地库函数，并且需要在客户端机器上安装TDengine，在项目部署阶段会稍微麻烦一些，但总体来说，利大于弊。

　　最近更新了官方的 JDBC-RESTful 方法，支持跨平台功能。由于公司服务器的操作系统都是Linux，没有跨平台的要求，所以还是使用了JDBC-JNI Connector。

　　注：图片来自TDengine官网

　　数据库连接池和ORM

　　数据库连接池和ORM框架也选择了公司主流的Druid+Mybatis。根据官网的Demo代码，也可以高效完成访问。但是在Mybatis的使用中，Mybatis只用在查询中，把ResultSet转换成更方便的实体，写数据的时候不使用Mybatis。为方便起见，直接在内存中拼接sql后执行。

　　总的来说，TDengine在适配主流框架方面非常友好，支持HikariCP、Druid、Spring JdbcTemplate、Mybatis等，根据官网提供的Demo可以快速访问，节省不少时间，一些预防措施文件明确列出。

　　集群建设

　　目前TDengine集群共有3个物理节点，均为16核/64G内存/1T存储。

　　官方的集群搭建文档非常详细，可以直接按照文档进行傻瓜式操作搭建TDengine集群。

　　建立图书馆

　　在初步调查中发现，假设集群中只有三台机器，如果数据量太大，则副本数为3，相当于每台机器存储一个完整的数据。压力会很大，所以建库的时候副本数设置为1。如果未来集群规模扩大，TDengine还支持动态修改副本数，可以轻松完成向高可用集群的切换。

　　

　　另外，考虑到查询性能，blocks设置为16，cache设置为64MB。

　　CREATE DATABASE sentinel KEEP 365 DAYS 1 blocks 16 cache 64;

　　表现

　　目前，TDengine承载着百亿级数据，在生产环境中运行流畅。每日CPU使用率低于1%，内存使用率稳定在25%以下。

　　下图是集群中某台机器的监控图：

　　使用TDengine早期版本（2.0.7.0）进行研究时，内存存在一些缺陷，但随着版本的迭代，内存问题得到了较好的解决。

　　写入性能

　　控制台机配置4核16G，批量写入线程池中设置的最大核心线程数为16，数据库连接池中的最大线程数为20，实际使用量为14左右。

　　编写过程如下：

　　批量写入设置的最大写入条目数为400，写入时间如下：

　　可以看出，*敏*感*词*写入的耗时基本可以保持在10ms，是一个比较理想的范围。SQL 语句的最大长度尚未调整，未来可能会通过增加 SQL 语句的长度来进一步优化写入性能。

　　查询性能

　　以下时间消耗不包括网络开销等，数据来源于客户端对指定SQL语句的查询。超级表中查询的数据量在百亿级别。下面给出几种典型场景的时间消耗：

　　无论是大数据量范围内的聚合查询，还是某个单元格内所有数据的指定查询，查询效率还是非常不错的。

　　并且与前期研究的数据相比，新版本的查询性能优化了不少，相信在未来的版本迭代中，会进一步提升。

　　贮存

　　目前Sentinel的数据没有复制，全量数据分散在三台机器上。根据计算，TDengine可以将Sentinel的监控数据压缩10%，相当可观。

　　总结

　　目前TDengine在德物只是作为时序数据库的小规模试点，流计算、内置查询功能等一些高级功能并没有使用。其作为时序数据库的读写性能和存储性能都令人满意。.

　　另外，运维难度和学习成本也出乎意料的低，而且很容易搭建一套可用的集群，这也是一个巨大的优势。另外，TDengine的版本迭代速度非常快，老版本遇到的一些问题很快得到修复，性能优化的效果也非常显着。

　　在研究和使用TDengine期间，另一个很重要的感受就是官方文档真的很详细。有很多事情; 引导类的文章步骤清晰简单，大大降低了学习成本，让开发者可以快速完成框架适配、集群搭建、SQL编写等。

　　未来，我们将持续跟进TDengine的发布说明，了解新特性、优化点、bug修复等，并在必要时进行版本升级。

　　预计TDengine的性能和稳定性会不断提升，未来也将作为其他适合业务场景的技术选型备选方案之一。流量控制数据。

　　注：本文数据基于TDengine 2.0.7.0和2.0.12.1版本。

　　文字｜天猫