TikTok美国控制权争夺战落下帷幕

1.引言 2025年1月我曾经发起了一个投票预测TikTok在美国的前景。下面是当时投票结果。 只能说大多数时候真理掌握在大多数人手中,TikTok美国的结局和大家预测的完全一致。 美国总统特朗普周四(26日)签署行政命令,正式批准TikTok在美业务的重组交易,允许该短视频平台继续在美国运营,同时符合美国国家安全法规的要求。根据交易条款,TikTok美国业务将由新成立的合资公司接管,而中国母公司字节跳动的持股比例将降至20%以下,以避免被视为完全由中国企业控制。 据CNBC引述消息指出,美国软件巨头甲骨文(Oracle)、私募基金Silver Lake,以及阿布扎比主权基金支持的MGX,将共同投资TikTok美国业务,合计持股约45%。字节跳动则保留19.9%的股份,其余35%股权由字节跳动的现有投资者持有,包括红杉资本、泛大西洋投资等机构。 根据协议,TikTok美国业务将由新成立的合资公司独立运营,甲骨文将负责数据托管,以确保美国用户信息不流向中国。这项安排旨在缓解美国政府对数据安全的疑虑,并符合《保护美国人数据免受外国对手侵害法案》(Protecting Americans’ Data from Foreign Adversaries Act)的要求。 2. TikTok美国的重组方案不是“云上德州” 按照当前媒体公布的股权结构,字节跳动的持股比例将从39.1%下降到19.9%,控制力进一步减弱。 甲骨文继续负责数据托管。 3. TikTok美国的股权重组真的是因为数据安全吗? 其实TikTok为了能够在海外运营,之前已经做了大量的合规工作。 数据合规措施 1) 数据存储与访问管理 2022年,TikTok成立了TikTok美国数据安全公司(TikTok U.S. Data Security Inc.),实施技术和运营保障措施。 美国用户的受保护数据默认存储于甲骨文的云服务器上,仅受批准的TikTok美国数据安全公司人员可访问。 2) 第三方代码审查 甲骨文在内的第三方已对TikTok进行了两年的代码审查,确保TikTok数据安全。 3) 透明度中心 2020年3月,TikTok建立了“透明度和问责中心”(Transparency and Accountability Center),并发布《透明度报告》。 受邀访客可以在这里参观TikTok的内容审核后台系统,看到APP的一些代码及其他数据管理操作。 4) 数据本地化存储 2025年2月,TikTok正式启用全新“数据本地化存储”方案,所有欧洲用户数据将完全迁移至爱尔兰与挪威的专属数据中心,并由第三方独立机构监督数据访问权限。 5) 用户控制权 TikTok赋予用户对自己数据的控制权。用户可以访问自己的个人资料,查看、编辑或删除个人信息。 6) 未成年人保护 针对未成年人用户,TikTok实施了更为严格的数据保护政策。平台限制了对未成年人数据的收集,并提供了家长控制功能,允许家长监督和管理孩子的账户活动。 TikTok美国股权重组之前和之后用户数据都是由甲骨文托管,怎么之前就不安全,重组完成之后就安全了?股权重组之前和股权重组之后的甲骨文是2个不同的甲骨文? 4.总结 我更愿意用一个形象的小故事来形容TikTok美国股权重组的性质。 ① 旧社会的时候,你是一个外地来的生意人,在某条街上开了一间包子铺,客人盈门,生意很好。 ② 这时候街面上的混混出来了,跟你说“生意不错嘛?让我也入一股,有钱大家赚嘛” ③ 你不愿意,然后各种流言就起来了,什么“包子铺不卫生,肉都是馊的”,连卫生部门频繁来检查了。 ④ 没办法,强龙不压地头蛇,你只能让混混入股。 ⑤ 各种流言自动消失了,卫生部门也不来检查了。 好吧,股权重组之后。大家就都是自己人了。TikTok应该能够美国安心的运营下去了。 这应该算是众多结局中,最好的一个了吧。

September 29, 2025 · 1 min

开源密码管理小工具 vearne/mypwbox

1. 引子 日常总有很多的密码需要存储,除了使用chrome浏览器的密码管理工具,还有一些其它场景,比如二次密码验证。 2019年萌叔开发了一款纯命令行管理工具 vearne/passwordbox 2024年底,我又在AI的帮助下开发了跨平台的App。vearne/mypwbox 2. 特征和用法 Flutter编写,支持跨平台(需要自己build) 支持国际化,当前支持 中文 或 English 支持使用对象存储(S3协议)进行在线同步&备份(可选,默认为离线) 支持一次性密码 任何支持S3协议的对象存储都可以被使用 AWS S3 Aliyun OSS Tencent COS MinIO 如果密码被用于二次验证且形如 otpauth://totp/ut:vearne?algorithm=SHA1&digits=6&issuer=ut&period=30&secret=XXXXXXXXXXXXXXXXXXXXXXXX 则可以显示对应的基于时间的一次性密码 警告: 关键密码不宜存储于电子文档中,最安全的方式是牢记于心。 作者: vearne 文章标题: 开源密码管理小工具 vearne/mypwbox 发表时间: 2025年01月17日 文章链接: https://vearne.cc/archives/40249 版权说明: CC BY-NC-ND 4.0 DEED

January 17, 2025 · 1 min

数据迁移总结

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1.前言 工作这么多年以来,萌叔参与过2次比较大的数据迁移。一次是将几十个T的舆情数据,从IDC-A迁移到IDC-B;一次是账号体系变更,处理100w+用户账号和权益变更。 在这中间遇到过很多问题,也踩过不少坑。本文稍作总结,希望对读者有所帮助。 2. 迁移流程的建议 建议你按照以下流程,来执行数据迁移流程 1)制定预案 需要充分考虑底量数据和增量数据的迁移问题 如果在数据迁移期间,有两套系统需要同时运行,如何保证数据的一致性 如何处理数据迁移引起的用户投诉? 数据迁移耗时? 像之前我们迁移几十个T的舆情数据,大概花费了1个月的时间 被迁移的数据是否要带上特殊标记(染色) 对内外部用户是否会造成影响?对其它第三方服务是否会造成影响? 1)如果需要调用上游服务的,数据迁移过程如果不限制对上游服务的访问,很可能导致上游服务崩溃 2)跨机房数据迁移,数据是走公网,还是走机房之间的专线。要不要限制网络带宽 3)数据迁移期间,可能会对数据库造成压力,会不会影响用户对系统的使用 详细列出数据迁移过程的多个Step 特别要注意多个Step之间有没有依赖关系 2)预案评估 组织会议,确保数据迁移可能影响的人员都能参与预案评估。 运营人员 产品经理 DBA 网络工程师 开发人员 客服 需要对与会人员说明: 整个迁移过程的耗时, 可能对内外部用户可能造成的影响 对上下游服务可能造成的影响,对网络带宽造成的影响 数据迁移的过程不引起问题是非常难的,关键是给相关人员一个预期,做到心理有数。 3)迁移脚本(程序)开发 是自己写脚本来执行数据迁移,还是使用Spark等大数据工具。这个也是需要好好考量的。 4)演练(演习) 由于数据迁移的总耗时,对内外部用户造成的影响, 对其他服务造成的影响很难评估, 尤其是如果整个数据迁移过程非常复杂,涉及多个步骤时。 比如萌叔在做账号体系相关的数据迁移,一共涉及15个步骤,这些步骤之间还有一定依赖关系。 所以萌叔强烈建议,要做数据迁移的演练。 mock数据测试 小样本集数据测试 5)按照预案实施 数据迁移的过程,要尽可能按照预案进行实施。 建议: 详细记录每个步骤开始和结束的时间点 6)数据校验 要考虑数据迁移完成之后,如何进行数据校验。(记录的数量,数据的状态一致等等) 对于非核心的数据甚至可以接受一定的差异,比如1% ~ 5%的数据差异。 7)事后总结 计划永远赶不上变化,有时候因为一些原因,数据迁移后的,数据的状态可能无法于预想的结果的一致,所以很有必要在数据迁移完成之后, 向相关方报告任务执行的结果。那些情况于计划的不一致,可能导致那些后果。

August 11, 2023 · 1 min

QPS、并发数与限流保护漫聊

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1.引言 Google的网站可靠性工程师小组(SRE)定义了四个需要监控的关键指标。他们称之为“四个黄金信号”:延迟(Latency),流量(Traffic),错误(Errors)和饱和度(Saturation)。这些与微服务的RED度量密切相关:速率,错误和持续时间,以及关注利用率,饱和度和错误的USE方法。这四个信号应该是服务级别目标(SLO)的关键部分,因为它们对于提供高可用性的服务至关重要。 流量(Traffic) 其中流量可以很多指标来衡量,比如QPS(每秒处理的请求数)、Inbound Bandwidth(输入带宽)、Outbound Bandwidth(输出带宽)等。 2.Little’s law QPS: query per second,每秒处理的请求数 RT: response time,平均响应时间或平均处理时间 Concurrent:并发数 QPS、RT、Concurrent之间存在如下关系: Concurrent = QPS * RT 某个服务可以被想象成一条单向高速公路。 每一个需要处理的请求或者任务可以想象成正在这条公路上行驶的汽车。 汽车从入口驶入,到从出口驶出所需要的时间就是平均响应时间(RT) 当前公路上的所有车辆数就是并发数(Concurrent),它一个瞬时值 车辆流速稳定后(从入口驶入和从出口驶出的速率 相同),每秒从入口驶入的车辆数就是每秒处理的请求数(QPS) 3.定性分析 3.1 RT变大 如果服务处理任务的过程依赖其它服务,比如MySQL、或者第三方服务。如果第三方服务出现问题,处理时间变长(RT变大),在QPS不变的情况下,由Little’s law可知,Concurrent会变大 3.2 QPS 如果客户端调用量突然增大,即QPS增大,RT不变的情况下,由Little’s law可知,Concurrent也会变大 3.3 请求触达速率和请求完成速率不一致 这种情况对于处理长作业的服务尤为明显。如果任务到达的快,处理的慢,那么通常只有2个结局,要么提交任务的时候,任务被直接拒绝,要么任务被扔在某个等待队列中,等待执行。在外部的用户看来,这些任务都是在并发执行中,可以看做是并发数。 4. 限流保护 在很多服务中,针对每个请求,都会独立分配额外的资源。比如Golang的web框架在gin中,每个连接都会分配3个协程;MySQL会针对每个请求创建User Thread),如果并发数一直增大,则服务很可能会被OOM或者陷入某种假死状态。 Concurrent = QPS * RT 结论 由于并发数受到2个变量QPS和RT的影响,RT受到第三方服务的影响而不可控,因此仅对QPS限制是无法保护服务的,还需要对Concurrent进行限制。 参考资料 1.Little’s law 2.QPS和并发数,这次给你说清楚 3.QPS、TPS、RT、并发数、吞吐量理解和性能优化深入思考

February 28, 2023 · 1 min

如何高效地阅读开源项目源代码

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1.引言 这篇文章是萌叔对阅读开源项目源代码的一般思路和方法的总结。 2. 带着问题去阅读? 首先需要搞清楚为什么你要阅读这个项目的源代码?你想从阅读这个开源项目获得什么? 是看项目的代码如何布局? 以RocketMQ为例,你是想了解为什么RocketMQ有强大的吞吐能力? 以RocketMQ为例,Clustering模式下,同组的消费者如何保证负载均衡? 以RocketMQ为例,你是想了解死信队列的作用? 总之需要在阅读之前多给自己提问题?在阅读的过程中也要给自己不断的提问题。 一个成熟的开源项目的源代码动辄就是上万行。根据二八法则,其实核心的代码顶多就是20%,剩下的大量都是参数解析,判断各种条件,处理错误、异常情况等防御性编码。在阅读时,要学会跳过这些代码,只关注自己感兴趣的代码,以节约时间。 3. 阅读官方文档并使用一段时间后,再去阅读源代码 “没有调查,没有发言权”–李德胜 建议先阅读官方文档,并针对开源项目对应的工具或者服务使用一段时间,再去看源码。官方文档中往往会有关于这个服务的架构说明,核心原理的讲解,有的还会给出最佳实践,这对于我们快速理解这个项目的有很大的帮助。 使用一段时间有助于加深对项目的理解,了解它的应用场景,优点和缺点,也可以在脑海中产生更多的问题。如果是服务,能够亲手搭建一次最好,特别是要关注配置文件中的参数说明,留意哪些参数可能对服务性能造成的影响。 4. 站在巨人的肩膀上 充分借鉴前人的智慧,搜搜已经公开的资料,看有没有诸如 “xxx源码解析” “xxx原理” “xxx总结” “xxx过程分析” 如果运气好,已经有人对你疑惑的问题做出了解答。如果运气再好点,说不定还会把核心代码涉及的文件、函数列得清清楚楚,这样通常我们只需要沿着文章的脉络把核心代码再看一遍即可。 5. 从哪里开始? 5.1 顺着接口往里看 对于有接口的服务,可以顺着接口往里看,从接收到请求开始,到最后输出响应结果 5.2 从数据库看起 对于有数据库的服务,还可以从数据库表结构看起,看都针对数据库表都有哪些操作 5.3 从Example和单元测试看起 example和单元测试往往都是侧重一个场景。从特定场景入手会比较好理解 6. 抓住核心脉络 6.1 数据流&控制流 绝大多工具或者服务都可以看做过滤器 所以我们只要关注数据在系统中的流动就可以了,还有的系统除了数据流之外,还有单独的控制流 6.2 状态机 一些系统内部有比较多的状态,比如订单系统,这种情况我们可以手绘一下状态机,多关注一下状态变换所需要触发的条件。 7. 举一反三,多做对比 比如我们再看RocketMQ源码的时候,我们就可以想想它和kafka在架构上有什么不同,各有什么优点缺点。 8. 多做分享 人们对一个知识的理解程度往往可以分为三个层次。 当你能够把看完的一个开源项目,并能够给其他人讲明白的时候,你才算是真的搞明白了。另外分享的过程也是查余补缺的过程,一些原先你没有关注的点,可以重新熟悉起来。在分享的过程中,与他人交流的过程,思想的碰撞往往带来新的火花。 萌叔认为 技术分享是利人利己的好事,大家可以多做。 总结 以上就是萌叔的阅读源代码的经验总结,希望对大家有所帮助。

October 21, 2022 · 1 min

RocketMQ架构设计中的"暴力美学"(1)-NameServer高可用

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1.引言 人们在潜意识里,总会觉得复杂且精巧的东西是好东西。但是这个复杂这个词在软件架构设计中,却不一定是好事情。因为过于精巧和复杂的系统往往意味着系统更难以维护,出现问题后,故障更难排查。萌叔在阅读和分享RocketMQ的过程中,发现它有很多设计非常的简单粗暴,堪称"暴力美学"的典范,同时又给人眼前一亮的感觉(还能这么玩)。 2. NameServer高可用 在RocketMQ的架构体系中,NameServer的作用类似于注册中心,Broker会周期性的向NameServer发送心跳,注册Topic信息。Producer和Consumer会向NameServer查询某个Topic的路由信息(Topic位于哪个Broker) Topic路由信息 { "OrderTopicConf": "", "queueDatas": [{ "brokerName": "broker-3", "readQueueNums": 4, "writeQueueNums": 4, "perm": 6, "topicSynFlag": 0 }, { "brokerName": "broker-4", "readQueueNums": 4, "writeQueueNums": 4, "perm": 6, "topicSynFlag": 0 }], ... } 如上面所示,某个Topic位于broker-3和broker-4,每个Broker上有4个MessageQueue 那么如何保证部分NameServer实例宕机后,注册中心的功能仍然能够正常运转呢? 按照正常点的想法,肯定是NameServer分成Master和Slave,然后Master和Slave之间在加上数据同步,如果Master宕机了,只要进行主从切换即可。这种做法肯定没问题,毕竟Hadoop中的NameNode也就是这么做的。 RocketMQ中的实现要简单的多,每个NameServer相互独立,并且它们之间没有通信。Broker会向每一个NameServer、NameServer1、NameServer2等等发送心跳,心跳中包含有它所维护的每个Topic的信息),这样每个NameServer就都含有路由信息。 等到Producer和Consumer向NameServer查询路由信息时,它会尝试向每一个NameServer进行请求。 下面的代码萌叔使用的是rocketmq-client-go的代码,因为rocketmq-client-go比Java的代码更加明显。 internal/route.go#queryTopicRouteInfoFromServer func (s *namesrvs) queryTopicRouteInfoFromServer(topic string) (*TopicRouteData, error) { request := &GetRouteInfoRequestHeader{ Topic: topic, } var ( response *remote.RemotingCommand err error ) ... // 遍历每一个NameServer for i := 0; i < s.Size(); i++ { rc := remote.NewRemotingCommand(ReqGetRouteInfoByTopic, request, nil) ctx, cancel := context.WithTimeout(context.Background(), requestTimeout) response, err = s.nameSrvClient.InvokeSync(ctx, s.getNameServerAddress(), rc) if err == nil { cancel() break } cancel() } if err != nil { rlog.Error("connect to namesrv failed.", map[string]interface{}{ "namesrv": s, "topic": topic, }) return nil, primitive.NewRemotingErr(err.Error()) } switch response.Code { case ResSuccess: if response.Body == nil { return nil, primitive.NewMQClientErr(response.Code, response.Remark) } routeData := &TopicRouteData{} err = routeData.decode(string(response.Body)) if err != nil { rlog.Warning("decode TopicRouteData error: %s", map[string]interface{}{ rlog.LogKeyUnderlayError: err, "topic": topic, }) return nil, err } return routeData, nil case ResTopicNotExist: return nil, ErrTopicNotExist default: return nil, primitive.NewMQClientErr(response.Code, response.Remark) } }

December 7, 2021 · 1 min

服务调优经验总结

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 前言 萌叔工作十多年,有不少服务调优的经验,在这里整理一下思路。希望对自己和同行有所帮助。 1. 发现问题 1.1 发现问题比解决问题难度更大 找出系统瓶颈和问题难度很大,一般只要能够找出且能够稳定复现,问题都能够被解决。 1.2 压测能够帮我们发现系统瓶颈,找出问题 压测不仅可以帮助我们发现系统瓶颈,还能用于发现死锁问题 1.3 尽可能细粒度的监控指标对发现问题帮助很大 讲几个容易忽略的细节 使用Cache的场景,要留意Cache的命中率 使用Channel的细节,要监控channel的长度,注意Channel是否写满,阻塞其它协程 对于比较复杂的接口,如果延迟高,需要有tracing记录,关注到底是那个环节耗时过多 对于MQ和数据库的场景,甚至还需要监控PageCache的命中率和使用情况、磁盘IO等等 GC 的耗时(特别是Java中Full GC) 2. 常见的思路 2.1 绝大多数服务的系统瓶颈是IO 我们接触到的绝大多数服务,都是IO型服务,影响延迟的主要因素是IO,磁盘IO、网络IO,数据库、微服务的响应延迟等等 2.2 如果CPU是瓶颈,需要有火焰图,关注是哪个环节消耗的CPU过多?每个部分占比是否合理?(注意压测) 比如是否大量的CPU时间被消耗在了锁竞争、上下文切换、垃圾回收、调度等。 在Golang中,由于锁中含有自旋锁,如果对锁的竞争激烈,会有大量的CPU时间被消耗在锁上。 在Golang中,P设置不合理也会导致大量的上下文切换 见文章 GOMAXPROCS你设置对了吗? 2.3 某一类型的服务,往往会有一组需要额外注意的核心指标 某些特定的服务容易受到特定因素的影响,比如 基于模型的分类器,压测时要特别关注它的CPU使用率是否能够跑满 见文章 AI预测模型工程化性能调优 数据库服务要留意磁盘IO 2.4 GC 有GC的场景,还要特别留意GC可能带来的负面影响 2.5 日志对服务性能影响不小 写文件和写控制台的性能差不多, 每秒钟差不多30w条。假定一个请求产生30条日志,也就是说即使处理这个请求没有任何逻辑,光是打日志,QPS也就差不多1w左右。(这也是很多服务压测的QPS无法超过1w的原因)。 见文章 玩转高性能日志库ZAP(5)-异步写日志 当你不知道该怎么调优的时候,可以试试关闭所有日志看看。? 3. 常见的优化手段 3.1 串行变并发 在IO型服务非常常见 3.2 同步变异步 常见的场景是回写数据库 3.3 单条变批量 比如数据需要回写数据库,可以在内存中缓存一拨,批量回写数据库,可以减少网络开销,降低数据库的开销 另外像写日志文件,批量写可以减少系统调用,提高写入效率。 笔者之前曾做过测试,将日志从单条同步写改为异步批量写,吞吐能力提升了1倍多。 见文章 玩转高性能日志库ZAP(5)-异步写日志 3.4 善用Cache 在多读少写的服务中,Cache对提升服务的能力,降低延迟,效果非常显著。(别忘了监控Cache) ...

December 4, 2021 · 1 min

那些年我用过的WordPress插件

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 前言 萌叔使用WordPress + Markdown的组合方式写blog已经有好几年了。在这篇文章中,笔者将会分享一些我曾经或者正在用的WordPress插件。 2. 插件 2.1 WP HyperMD Markdown编辑器,至今运行良好 对萌叔而言,用Markdown写文章写得更快,且不必要专注样式细节,而专注于内容本省。 2.2 Akismet Anti-Spam 反垃圾评论的,很好用 2.3 Cool Tag Cloud 一个简单但非常漂亮的标签云 效果如下图 2.4 Google XML Sitemaps 站点地图生成器,提高SEO效果。友情提示,别忘了将站点地图的地址提交给常用的搜索引擎。 本站的站点地图URI sitemap 2.5 Login LockDown 防止恶意程序采用暴力登录的方式,攻击网站。它的原理,如果来自某个IP的用户,在5分钟内连续3次登陆失败。将会禁止在未来的1个小时内,禁止来自这个IP的登录行为。 这个插件,萌叔非常推荐。如果你细心观察访问日志,来自互联网的恶意登录(主要是基于密码字典)非常普遍,使用Login LockDown可以增大恶意程序的攻击难度。另外建议用户名不使用"admin"、“root”, 密码一定使用强密码。 2.6 NoSpamNX 保护博客免受自动垃圾评论机器人的侵扰 2.7 WordPress Related Posts 它通过在内容页脚添加"相关推荐",提高整个网站的page view 效果形如 2.8 WP Super Cache WordPress的快速缓存插件 对动态页面进行静态缓存,可以抗一定量并发,并节约服务器资源。 2.9 Simple Google reCAPTCHA 借助Google reCAPTCHA,简单保护您的WordPress免受垃圾邮件评论和暴力攻击即可! 这个插件其实是个相当好的东西,相当于验证码的作用,可以阻止机器人的暴力攻击。不过由于墙的存在,导致这个插件依赖的JS文件经常加载失败,所以我把它禁用了。 2.10 Hide WP Login 由于wordpress的登录地址是固定的,所以很容易受到黑客的暴力登录的方式攻击。使用Hide WP Login可以隐藏网站的登录地址,或者要求访问登录页面时,比如携带特定的key。 ...

August 4, 2020 · 1 min

elasticsearch如何存储关联关系?

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 前言 之所以写这篇文章是因为我已经在不止一个群里,看到有人问如何在ES中存储关联关系。 2. 答案 你可能会在网上看到有说Join datatype和Nested data type的,但是其实这都不是ES该有的玩法。 Join datatype和Nested data type都会涉及多次查询的开销 Join datatype本身的数据就是在不同的表中,对于分布式数据库,还涉及数据从不同的节点上拉取和组装的开销。 那么应该怎么做?答案就是用冗余的宽表来存储关联关系 举例说明 假如我需要在ES中存储的实体有书籍、书籍有作者信息、书名等等信息,显然实体之间有如下关系 如果在传统的关系型数据库中,就需要创建2张表,一张表表示作者,一张表代表书。但是对于nosql数据库,只需要一张表(书)即可,doc结构形如: { "name":"zhangsan", "publisher_identifier": "xxx-xxxx-xxx" "author":{ "name": "jobs", "phone": "111111111" } } 作者信息作为书的属性存储在一起,放一个doc中即可。 这样的做法必然是会带来数据冗余,但是以空间换时间,查询速度就有了保障。 现代的nosql数据库大多应对的海量数据的存储查询的问题,因此大都是分布式结构。在这种情况下,整体的设计方案必须足够简单,才能够易于维护和扩展。同样的做法,也完全适用于HBase。 3. 说几句某些人可能不爱听的话 ES集群的使用成本其实是很贵的,用了就别怕贵,觉得烧钱就别用 ES自身的性能优化工作做得还是很好的,对大多数人而言,不需要考虑优化,性能不够,就老老实实的加硬件就行。高版本相比低版本性能和稳定性都有很大的提升,优先考虑高版本 SSD对ES的性能提升非常明显(便宜不一定不是好货,但好货一定不便宜) 4. 参考资料 1.Join datatype 2.Nested data type 3.宽表和窄表的区别 打赏我

July 2, 2020 · 1 min

密码管理工具(命令行)

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 萌叔最近做一个类似1password的命令行密码管理工具passwordbox。传送门: vearne/passwordbox 支持使用对象存储进行多端同步(可选),目前支持阿里云OSS,青云QingStor 内部实现细节 首先将每个记录项加密存储在SQLite的数据文件中,然后再对整个数据文件进行二次加密。记录在内存中也是以密文的形式存在,安全系数比较高。 快速开始 编译 make build 安装 make install 启动 pwbox --data=/Users/vearne –data 设置加密数据文件的存储路径 建议你为passwordbox设置一个别名 alias pwbox='pwbox --data=/Users/vearne' 程序启动以后,按照导引的要求创建数据库,所有的记录项都存储在数据库中 ─$ ./pwbox --data /tmp/ ---- login database ---- ? Please type database's name: test fullpath /tmp/6879630a7d56210d2cd2491cb99d781194689fed71d7890a8dabbcb3a678cb73 ? Database is not exist. Do you like to create database now? Yes ---- create database ---- ? Please type database's name: test ? Please type password: ***** ? Please type hint[optional]: test ---- login database ---- ? Please type database's name: test fullpath /tmp/6879630a7d56210d2cd2491cb99d781194689fed71d7890a8dabbcb3a678cb73 ? Please type your password: ***** Hint for database test is test 登录数据库成功之后,可以执行如下的命令 ...

April 22, 2020 · 3 min