首页 文章 精选 留言 我的

精选列表

搜索[文件对比],共10042篇文章
优秀的个人博客,低调大师

Spring注解@Resource和@Autowired区别对比

@Resource和@Autowired都是做bean的注入时使用,其实@Resource并不是Spring的注解,它的包是javax.annotation.Resource,需要导入,但是Spring支持该注解的注入。 1、共同点 两者都可以写在字段和setter方法上。两者如果都写在字段上,那么就不需要再写setter方法。 2、不同点 (1)@Autowired @Autowired为Spring提供的注解,需要导入包org.springframework.beans.factory.annotation.Autowired;只按照byType注入。 publicclassTestServiceImpl{ // 下面两种@Autowired只要使用一种即可 @Autowired privateUserDao userDao;// 用于字段上 @Autowired publicvoidsetUserDao(UserDao userDao){ // 用于属性的方法上 this.userDao = userDao; } } @Autowired注解是按照类型(byType)装配依赖对象,默认情况下它要求依赖对象必须存在,如果允许null值,可以设置它的required属性为false。如果我们想使用按照名称(byName)来装配,可以结合@Qualifier注解一起使用。如下: publicclassTestServiceImpl{ @Autowired @Qualifier("userDao") private UserDao userDao; } (2)@Resource @Resource默认按照ByName自动注入,由J2EE提供,需要导入包javax.annotation.Resource。@Resource有两个重要的属性:name和type,而Spring将@Resource注解的name属性解析为bean的名字,而type属性则解析为bean的类型。 所以,如果使用name属性,则使用byName的自动注入策略,而使用type属性时则使用byType自动注入策略。如果既不制定name也不制定type属性,这时将通过反射机制使用byName自动注入策略。 publicclassTestServiceImpl{ // 下面两种@Resource只要使用一种即可 @Resource(name="userDao") privateUserDao userDao;// 用于字段上 @Resource(name="userDao") publicvoidsetUserDao(UserDao userDao){ // 用于属性的setter方法上 this.userDao = userDao; } } 注:最好是将@Resource放在setter方法上,因为这样更符合面向对象的思想,通过set、get去操作属性,而不是直接去操作属性。 @Resource装配顺序: ①如果同时指定了name和type,则从Spring上下文中找到唯一匹配的bean进行装配,找不到则抛出异常。 ②如果指定了name,则从上下文中查找名称(id)匹配的bean进行装配,找不到则抛出异常。 ③如果指定了type,则从上下文中找到类似匹配的唯一bean进行装配,找不到或是找到多个,都会抛出异常。 ④如果既没有指定name,又没有指定type,则自动按照byName方式进行装配;如果没有匹配,则回退为一个原始类型进行匹配,如果匹配则自动装配。 @Resource的作用相当于@Autowired,只不过@Autowired按照byType自动注入。 迎工作一到五年的Java程序员朋友们加入Java架构开发:744677563 本群提供免费的学习指导 架构资料 以及免费的解答 不懂得问题都可以在本群提出来 之后还会有职业生涯规划以及面试指导

优秀的个人博客,低调大师

Kubernets日志采集配置模式介绍与对比

日志服务支持通过Logtail采集Kubernetes(简称K8S)集群日志,并支持CRD(CustomResourceDefinition)和控制台等方式进行采集配置管理。 为提供更优的扩展性、灵活性,Logtail采集的配置与K8S中的Deploy/Pod配置完全解耦,两者可以一起部署也可以独立部署,具体取决于您的实际应用和业务需求。 下面我们介绍几种典型的配置方式,以便于您在实际应用中进行参考。 前提 K8S环境中安装好Logtail相关服务组件,若未安装请参考Kubernetes日志采集部署相关组件。 假设您对K8S中服务部署已经具备一定基础知识。 注意事项 K8S集群Logtail组件部署完毕后,会默认创建一个自定义标识的机器分组,后续所有的配置直接应用到该分组即可。 Logtail容器在K8S中以DaemonSet的模式部署,后续您的

优秀的个人博客,低调大师

“行”“列”对比 Sybase IQ酷在哪里?

500年前,高层建筑,如同行式数据库一般,由墙壁提供水平支撑。由于当时钢铁数量有限、价格昂贵,如此大型的建筑物在高度上受到限制。美国最早期的高层建筑之一就是纽约市摩天大楼“世界大楼”,它高309英尺,共20层,建于1890年。台湾的台北101楼高1474英尺,共101层。诸如此类的现代摩天大楼则是垂直支撑在钢骨架上。目前,台北101是世界上最高的建筑物。但第一的地位很快将被取代。迪拜目前正在建造更高的建筑。这些现代摩天大楼如同列式数据仓库一般,它们的楼高可以并且也将越来越高。 “列式数据仓库以更低成本提供更佳性能,而且所用空间比传统行式关系型数据仓库更小——因此,很难理解为什么那些特别关注查询性能的公司不考虑采纳列式解决方案。”PhilipHoward在他洋洋洒洒的报告《“列”酷在哪里?(What'sCoolAboutColumns)》的结尾处写道。该报告发表于2008年3月,是专门提供给欧洲主要信息技术分析组织Bloor研究公司的。 不断成长 事实上,列式数据仓库——SybaseIQ分析服务器——是由其与SunSPARCEnterpriseM9000Server和BMMsoftServer共同打造而成的全球最大的数据仓库的核心。这一开创纪录的成就涉及1PB(即1035TB)的原始数据。(详情请见《2009年吉尼斯世界记录》第144页) 我们知道列式数据仓库其实是由Sybase于1993年首创、并在1996年发布的,但近期发生的众多列式数据仓库的相关事件却才刚刚吸引人们的广泛关注。这或许会让人感到困惑,因为在其经过12年发展的今天,SybaseIQ才逐渐赢得主流市场的认同,列式数据仓库的竞争也开始表现得十分活跃。或许,正是上述表现,加上Sybase自身致力于向市场宣传其卓越的分析服务器,以及商业环境的变化(如人们要求在保持性能的同时降低成本)才是根源所在。 Bloor的Howard似乎同意这一观点:“在过去十年里,列式方法的使用在很大程度上一直是一个小众事件。”Howard注意到,近期有8个供应商进入到这个曾是Sybase独享的领域,且全球2000强公司越来越关注该领域,“我们相信,是时候让‘列’走出阴霾,成为数据仓库和相关市场的主要力量了。”他补充。 SybaseIQ目前约有1300名用户,由此可以说,如今的列式数据仓库已经走出了阴霾。在Bloor13页的报告中,Bloor详细说明了列式关系型数据库“可能曾经是什么”,和它们的作用、工作方法以及与传统关系型数据库相比的优势。早在2001年,GeoffreyMoore就评价说:它们是最根本、最前沿的技术。 当时,硅谷最优秀的技术大师之一、影响深远的商业书《跨越鸿沟》(CrossingtheChasm)一书的作者Moore认为,Sybase已经将经典的数据库行式架构模式“完全”改变为列式架构,提取数据的速度比传统数据库快100倍,而且支持与多人实时共享。“这是一种全新的模式,由此可以创造无限的市场机遇。”Moore特别强调了该产品的特点,“了解列式数据库对分析的含义。” 优势所在 来自全球最大的数据库专家Winter公司的RichardWinter在《新时代的高效数据仓储》白皮书(http://www.wintercorp.com)中如此解释SybaseIQ的架构:“它旨在支持大量用户的并发运行特别是查询。因此,该设计和工程过程……首先关注的是查询性能,其次是完成批量数据更新的速度,再次是小数据更新的性能。这一优先排序与通用引擎截然不同,后者用于在线交易处理和数据仓储(实际上,这通常更强调交易处理)。这样的引擎必须尝试同时实现复杂查询的交互性能和高容量在线更新。由于SybaseIQ的设计目标严格以数据仓储为主,其架构和性能特征相当明显,这有利于数据仓库用户。” 例如,拥有数百万用户的在线购物服务可能需要基本的查询功能。问题可能是:随着圣诞节的来临,过去3年有多少纽约人购买了珠宝?为了回答这一问题,行式数据库将需要50万次输入/输出(I/O)重新定向。因为,行式流程将需要处理大量不相关的数据。在SybaseIQ的列式操作中,要回答此问题则只需要234次I/O。这些数字是利用1600万行、在一个表格上进行计算而获得的。事实上,要进行适当的查询,从每一列获取的数据应始终小于从传统数据库获取的数据。这意味着I/O次数减少,因此列式数据库的性能更佳。行式数据库管理员试图通过构建数据的摘要、聚合和索引,解决与行相关的问题,但是优先采用列式数据库便可解决所有问题。 上述就是SybaseIQ的设计与传统数据库的不同之所在:前者专门定向,提供分析用商业情报仓库,而后者主要用于完善交易——两者的任务不同。 “与行式架构相比,‘将数据储存在列中’采纳压缩算法,提供了大量提高性能的机会。”来自麻省理工学院的三位作者在2006年的一份报告《列式数据库系统集成压缩和执行》中如此描述。三位作者分别是DanielJAbati、SamuelR.Madden和MiguelC.Ferreira。他们在报告中指出,在列式数据库中,采用一次性对多个值进行编码的压缩方案很自然。“而在行式数据库中,此类方案效果不佳,因为属性储存为整体元组(元素集)的一部分,因此将不同元组的相同属性,结合到一个值中将需要采取措施‘混合’元组。”他们解释。 来自Bloor的Howard写道:“从行到列的变化看起来微不足道,实际上意义深远。”正是由于人们越发认识到其意义深远,SybaseIQ的特殊分析列式存储才激发了如此大的热情。在业务环境下,任何人在开发数据价值的同时都随处面临数据超载的问题,他们也致力于寻求控制方法。此时,SybaseIQ的一个优势在于,其数据处理速度比传统方法快100倍。SybaseIQ的高速分析能力可几乎实时处理大量的特定查询。另一个优势在于,它仅处理可以回答这些查询的列,而不是分类整理与特定查询无关的数据行。这自然加快了流程。 此外,列式方法应用优化的压缩——效率高达10:1以上,同时,每个列的数据保持一致(种类、采购日期和地点)。这意味着可以使用更少的磁盘空间存储更多信息,从而提供更多可供分析的历史数据。 在SybaseIQ众多客户中,法国Prémalliance公司是法国国内主要的社会福利提供商。凭借SybaseIQ,该公司的技术成就脱颖而出,并荣获2008ComputerworldHonors(2008年计算机世界荣誉)的桂冠奖。 Premalliance需要整合和分析全球数据图表,展示其核心业务的福利合约所取得的商业、财务和技术成果。采用SybaseIQ的结果之一就是帮助Prémalliance完成其整合过程,并在不到5秒钟的时间内至少汇总3000万个数据行,而且不会对 服务器 造成巨大负荷。Prémalliance过去曾说,即使是为董事会董事准备报告也要求大量的IT资源投入,通常可以获得所需信息——但需要花2至3周才能将这些信息集合与组织起来。当然,今非昔比,Prémalliance仍有很多潜力可以挖掘,其发展可谓前程似锦。 尾声..转点论坛个人热论已普及一下sybaseIQ的新鲜玩意 提到发展方向,个人认为列式数据库在今后的发展中,应该考虑以下几个方向: 1,分布式计算:可能和楼上提的分布式列式数据库类似,希望看到可能是分步走的过程,先做CPU上面的分布;再做主机层面的分布;最后是存储层面的分布。这样可以更大地打开计算能力的瓶颈。列式数据库的列式存储的优势配合上分布式计算的优势,应该是未来的一个大方向。至于说叫不叫云计算都不重要。 2,进一步的索引优化:可能以新的索引的方式,可能以索引对查询/分析的使用方式等 3,分久必合,合久必分,我想行式数据库必定会有压力去突破,等行式数据库也慢慢地接受列式数据库带来的的技术冲击,最终我们会发现行式和列式其实在某一个层面上并没有那么大的差别,会某种意义上再合并起来,共同解决数据存储/使用的问题。 个人观点: 行式数据库存储的时候大部分是采用堆表的方式,随机插入优势明显,列式数据库如果数据即索引,则随机插入的开销要大。每一列都有次定位和插入的动作,索引本身的维护量不会少。列式数据库本身还有其它形式索引,和行式相似。 大量的修改(varchar)时行式存储难免产生行漂移。这点恐怕对行数据库不利。 大量随机删除时堆表的维护应该是好于索引的维护的。 所以OLTP上行式数据库肯定优于列式数据库。 目前IQ上的索引基本也就改良B树和改良位图两类。全文检索应该是不太合适的。 查询特别是大范围查询,列式数据库因为是压缩存放的,所以IO上优势应该是明显的, 但牵涉到多表关联时更多取决于连接的join算法问题、统计结果的存放问题。现在市面上的OLAP产品也多, MOLAP的产品在这方面的优势明显,ROLAP在一定程度上处于劣势,虽然IQ增加了joinindex但该索引的维护很夸张。如果不能再做到分布式的数据分布,后期的扩展就有问题了。 分布式列式数据库在ROLAP上应该是发展方向。 很好的讨论,坐等各位高手的意见。 关于列式数据库你知道多少?存储结构不同,使用场景不同,老牌的数据库厂商目前只有sybase有很成熟的产品,并且有些成功案例。 你知道列式数据仓库是谁首创的吗?目前声音最响的是sybase,谁首创真还不知道。 你知道全球有多少家列式数据库厂商?Sybase是目前最大的一家,还有一些小的列式数据库厂商。 你知道列式数据库与传统行式数据库有什么不同吗?主要是存储模式不同而导致查询效率、存储效率、索引模式等等方面都和传统行式数据库有很大差异。从列式数据库的实现SybaseIQ而言,相同的地方在于标准的借口和对SQL标准的支持。 你对列式数据库持什么样的看法呢?目前主要应用于OLAP领域,包括查询、统计、报表、分析、历史数据存储等等方面,OLTP领域不适合。列式数据库应该是一个方向吧,目前SybaseIQ是一个影响最大的实现产品,期待其它DB巨头的表态,好像Oracle新版本也在准备支持,如果这样的话,应该是一个方向。 在BI系统中,一般批量ETL只是准备数据阶段, 在数据展现阶段还是会有大量的读操作。 当然,你也可以把数据展现交给OLAPSERVER去做,比如ESSBASE等。 但这样存在大量数据导入导出,构造CUBE等操作。 IQ当初的设计理念是 写节点处理批量ETL,读节点代替OLAPSERVER,直接支持各种报表类、分析类查询及ad-hoc查询。 因此,写节点需要高配置实现资源集中化,而读节点实现可扩展应付并发查询。 而且用读写节点物理分离的方式解决批处理与查询的资源竞争问题。 找了几条比较好的扫扫自己的盲点 本文转自My_King1 51CTO博客,原文链接:http://blog.51cto.com/apprentice/1360626,如需转载请自行联系原作者

优秀的个人博客,低调大师

呼叫中心几种常见质检方式的对比

如果将呼叫中心看做一个工厂,那么通话的电话就是呼叫中心生产的产品,大家都知道工厂出厂的产品不被质检是不会放心的投入到市场上去的,所以呼叫中心的录音也需要质检,唯一的不同是呼叫中心的质检有可能是抽检。很多人会问,呼叫中心为什么会是抽检而不是全部的录音都被质检呢?这中间主要的原因就是成本因素,但是到今天随着人工语音智能质检的出现,这个问题正在逐步的被解决。接下来,我们通过文章给大家简单的介绍几种质检方式的优缺点。 人工智能语音质检 1、首先人工智能语音质检到底是怎样质检的呢?首先人工语音机器人能够在客服代表与客户交流过程中,通过语音识别系统将语音转化成为文字(参考语音输入或讯飞输入法),并可以实现100%的质检覆盖。当然,强大的语音机器人可以实现对俚语、小语种的识别,妈妈再也不担心质检员听不懂方言了。将录音识别成文字后,通过企业前期录入系统中间的关键词、业务关键点、流程备注、话语重复次数要求等业务模型和服务模型要求对话务员进行业务质检。同时人工智能语音质检能够通过字数(字数/时间)、音量、声道、波动次数、通话静默检测客服代表的服务质量水平及情绪变化情况。通过声纹识别的方式区分服务场景,人工智能语音质检能对分客服与客户的对话进行场景分割,以此来进行数据分析(话务员部分用来质检、客户部分用来进行数据分析:比如营销政策或者客户需求分析等等)。 说了这么多,我们首先来总结一些人工智能质检的优缺点吧。 优点:质检效能高、质检覆盖率高、质检结果公平、可同频质检并在线提醒客户代表、分析报告数据可实时查看、节约人力成本等。 缺点:前期投入成本高(一般小型企业难以承担)、数据库数据巨大、建模麻烦(比如欢迎语需要有欢迎语的质检模型、不同的产品需要有不同产品的质检模型等)、语意需要持续更新、机器人质检无法考虑通话背景(如客服代表插话是否是沟通需要就很难通过机器人进行判别)、运用率较低。 适用范围:通用,但专题质检(如FCR分析等等)建议质检员还是人工听取录音比较好 同屏语音质检 2、同屏语音质检指的是质检员能够通过系统,对话务员进行实时质检,并且能够通过系统管理看到话务员直接的操作界面,并将质检结构直接记录与系统,用于数据分析。 优点:发现问题,解决问题迅速。能够迅速发现服务过程中的流程、人员、业务与客户期望质检的差距,并能及时提醒客服代表的差错并及时进行处理。 缺点:质检结果准确度不高,录音样本抽取不一定科学,适用范围小,质检员工作压力大等。 适应范围:特殊质检(如持续满意度底下的员工)以及新员工质检。 传统后置录音质检 3、该质检方式是目前大部分的呼叫中心在运用的质检方式,主要是通过后期质检员在线倾听客服代表录音的方式进行,将录音结果登记于表格之中并将表格进行数据分析,同样该质检的方式也有他的优缺点: 优点:客服反复听取录音、能有效发现服务存在的问题、一般而言质检结果的准确性更高、使用普遍性高、成熟度高、技术壁垒低、前期投入低等。 缺点:发现问题的时效性较差、无法第一时间直接处理服务过程中存在的问题、质检工作量大、效率低且覆盖率低,难以有效评价整体服务质量等。 适应范围:日常质检或专题质检。 以上三种为呼叫中心主要的语音质检方式,具体的优缺点与运用各位可以根据自己呼叫中心的特点进行甄别运用。下一专题我们将通过文章与大家交流质检标准的设置与质检表的设置逻辑。 本文转自d1net(转载)

优秀的个人博客,低调大师

Spark Streaming和Flink的Word Count对比

准备: nccat for windows/linux 都可以通过 TCP 套接字连接,从流数据中创建了一个 Spark DStream/ Flink DataSream, 然后进行处理, 时间窗口大小为10s因为 示例需要, 所以 需要下载一个netcat, 来构造流的输入。 代码: spark streaming package cn.kee.spark; public final class JavaNetworkWordCount { private static final Pattern SPACE = Pattern.compile(" "); public static void main(String[] args) throws Exception { if (args.length < 2) { System.err.println("Usage: JavaNetworkWordCount <hostname> <port>"); System.exit(1); } StreamingExamples.setStreamingLogLevels(); SparkConf sparkConf = new SparkConf().setAppName("JavaNetworkWordCount"); JavaStreamingContext ssc = new JavaStreamingContext(sparkConf, Durations.seconds(1)); JavaReceiverInputDStream<String> lines = ssc.socketTextStream( args[0], Integer.parseInt(args[1]), StorageLevels.MEMORY_AND_DISK_SER); JavaDStream<String> words = lines.flatMap(new FlatMapFunction<String, String>() { @Override public Iterator<String> call(String x) { return Arrays.asList(SPACE.split(x)).iterator(); } }); JavaPairDStream<String, Integer> wordCounts = words.mapToPair( new PairFunction<String, String, Integer>() { @Override public Tuple2<String, Integer> call(String s) { return new Tuple2<>(s, 1); } }).reduceByKey(new Function2<Integer, Integer, Integer>() { @Override public Integer call(Integer i1, Integer i2) { return i1 + i2; } }); wordCounts.print(); ssc.start(); ssc.awaitTermination(); } } Flink DataSream package cn.kee.flink; import org.apache.flink.api.common.functions.FlatMapFunction; import org.apache.flink.api.common.functions.ReduceFunction; import org.apache.flink.api.java.utils.ParameterTool; import org.apache.flink.streaming.api.datastream.DataStream; import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment; import org.apache.flink.streaming.api.windowing.time.Time; import org.apache.flink.util.Collector; /** * Example :SocketWindowWordCount * @author keehang * */ public class SocketWindowWordCount { public static void main(String[] args) throws Exception { // the port to connect to final int port = 9999; /*try { final ParameterTool params = ParameterTool.fromArgs(args); port = params.getInt("port"); } catch (Exception e) { System.err.println("No port specified. Please run 'SocketWindowWordCount --port <port>'"); return; }*/ // get the execution environment final StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); // get input data by connecting to the socket DataStream<String> text = env.socketTextStream("localhost", port, "\n"); // parse the data, group it, window it, and aggregate the counts DataStream<WordWithCount> windowCounts = text .flatMap(new FlatMapFunction<String, WordWithCount>() { @Override public void flatMap(String value, Collector<WordWithCount> out) { for (String word : value.split("\\s")) { out.collect(new WordWithCount(word, 1L)); } } }) .keyBy("word") .timeWindow(Time.seconds(5), Time.seconds(1)) .reduce(new ReduceFunction<WordWithCount>() { @Override public WordWithCount reduce(WordWithCount a, WordWithCount b) { return new WordWithCount(a.word, a.count + b.count); } }); // print the results with a single thread, rather than in parallel windowCounts.print().setParallelism(1); env.execute("Socket Window WordCount"); } } 结果: Spark是一种快速、通用的计算集群系统,Spark提出的最主要抽象概念是弹性分布式数据集(RDD),它是一个元素集合,划分到集群的各个节点上,可以被并行操作。用户也可以让Spark保留一个RDD在内存中,使其能在并行操作中被有效的重复使用。 Flink是可扩展的批处理和流式数据处理的数据处理平台,设计思想主要来源于Hadoop、MPP数据库、流式计算系统等,支持增量迭代计算。 总结:Spark和Flink全部都运行在Hadoop YARN上,性能为Flink > Spark > Hadoop(MR),迭代次数越多越明显,性能上,Flink优于Spark和Hadoop最主要的原因是Flink支持增量迭代,具有对迭代自动优化的功能 流式计算比较 它们都支持流式计算,Flink是一行一行处理,而Spark是基于数据片集合(RDD)进行小批量处理,所以Spark在流式处理方面,不可避免增加一些延时。Flink的流式计算跟Storm性能差不多,支持毫秒级计算,而Spark则只能支持秒级计算。 SQL支持 都支持,Spark对SQL的支持比Flink支持的范围要大一些,另外Spark支持对SQL的优化,而Flink支持主要是对API级的优化。 Spark 感觉2.x 后主要在spark sql 这里发展优势,快速Join操作,以及继续扩展sql支持。至于Flink,其对于流式计算和迭代计算支持力度将会更加增强。

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

用户登录
用户注册