- 综合排序
- 最热优先
- 最新优先
- 来自专栏音视频专栏
网络诊断方案选型
可用方案 （1）利用so库 执行底层的命令 （2）安装Linux层第三方库，使Android系统支持上述命令 （3）dnsjava 这两种方法分别有他们的缺点so库麻烦，并且体积大,而第二种方式需要root .讲最新获取的数据减去之前获取的数据并且除以间隔的秒数，就得到了每秒平均的网速b/s，最后进行单位 转换为kb、Mb等等 3. 现有网络诊断组件或者方案对比 （1）HttpInfo 比较强大，记录的信息包括 Index信息（域名以及请求时间） Net信息（手机网络信息） Ping信息 Http信息 Host信息 MtuScan信息 LDNetDiagnoService_Android 功能：ping、tcp connect和traceroute Android的实现方案一: 是通过后台线程执行ping命令的方式模拟traceroute ；（关于iputils工具原理实现，请参考博文） 这里用的方案2 （3）facebook/network-connection-class gitHub地址 用Android的接口实现的功能，只能测试下行的带宽
5K60发布于 2020-08-04 - 来自专栏全栈程序员必看
Mongo分库方案选型
Mongo分库方案两种形式分析： 1. mongo sharding方式： 1.1. 1.2. mongo sharding再平衡时，有可能查询数据出现重复的问题 当mongo sharding根据 sharding key，将数据存入mongo的5个片（1，2，3，4，5）时，一般会产生 5个分片数据不均匀的问题，假如1，2的分片数据较多，3，4，5的分片数据量较少，那么mongo sharding再平衡策略会将1，2分片上的数据平衡到3，4，5分片上，如果此时数据正在进行平衡，那么查询 1，2分片上的数据平衡到3，4，5的那部分的数据时，而且没有命中索引的情况时，有可能出现重复数据的现象。
46320编辑于 2022-09-12 - 来自专栏全栈程序员必看
无线充电器方案(方案选型)
目录 一篇读懂无线充电技术（附方案选型及原理分析） 0.背景 1.无线供电特点 1.1优点： 1.2 缺点 2. 3.3 充电阶段：进行电能传输 4.现有解决方案分析： 4.1 IDT无线IC方案 4.2 恩智浦 MW系列无线充电IC方案： 4.3 TI （BQ系列）无线充电方案 4.4 东芝无线IC方案 5. 参考资料 博主热门文章推荐： 一篇读懂无线充电技术（附方案选型及原理分析） 作者：HowieXue 0.背景 现今几乎所有的电子设备，如手机，MP3和笔记本电脑等，进行充电的方式主要是有线电能传输，既一端连接交流电源 （3）新颖性，用户体验好 （4）具有通用标准 主流的无线充电标准有：Qi标准、PMA标准、A4WP标准。 电源学报, 2014, 12(3):27-32. [2] 孟庆奎. 手机无线充电技术的研究[D]. 北京邮电大学, 2012. [3] 潘力. 一种锂电池无线充电模块的设计[D].
2.4K21编辑于 2022-08-01 - 来自专栏battcn
Mock API技术选型方案
技术选型 当下互联网行业已经从大鱼吃小鱼演变成快鱼吃慢鱼的时代了，从用户需求转化成企业服务的能力，研发效能的高低对用户需求转化速率起到了至关重要的作用，而API服务的研发效能是当中非常重要的一环。 建议 RAP1 长达3年+ 未更新维护，RAP2 长达1年+未更新维护，开源项目一档超过半年未迭代更新，选择就需要慎重，同时对比阿里对待开源的态度，不能商用大部分是KPI考核项目 如果是JAVA项目，可以采用 YAPI + Swagger 的方案,无缝集成,其它类型的项目也可以单独使用YAPI YAPI -> RAP2 -> Swagger -> RAP1 安装（推荐方式） 使用官方提供的 yapi-cli
1K30发布于 2021-09-23 - 来自专栏A周立SpringCloud
MySQL高可用方案选型参考
可选MySQL高可用方案 MySQL的各种高可用方案，大多是基于以下几种基础来部署的： 基于主从复制； 基于Galera协议； 基于NDB引擎； 基于中间件/proxy； 基于共享存储； 基于主机高可用 ； 在这些可选项中，最常见的就是基于主从复制的方案，其次是基于Galera的方案，我们重点说说这两种方案。 其余几种方案在生产上用的并不多，我们只简单说下。 基于主从复制的高可用方案 双节点主从 + keepalived/heartbeat 一般来说，中小型规模的时候，采用这种架构是最省事的。 在这个方案里，有几个需要注意的地方： 采用keepalived作为高可用方案时，两个节点最好都设置成BACKUP模式，避免因为意外情况下（比如脑裂）相互抢占导致往两个节点写入相同数据而引发冲突； 把两个节点的 老实说，我没实际用过，但从侧面了解到这种方案生产上用的并不多，可能也有些局限性所致吧； 以DBA们的聪明才智，肯定还有其他我不知道的方案，也欢迎同行们间多多交流。
1.3K10发布于 2019-07-10 - 来自专栏岛哥的质量效能笔记
弱网环境搭建方案选型
那今天来聊聊目前大致有哪些可以搭建弱网环境的方案以及各自存在的问题。 3、clumsy、netlimite等这类软件易安装，在电脑端安装后，手机通过共享网络连接电脑，实时的将系统接收和发出的网络数据包拦截下来，手动设置时延、丢包和篡改等操作后再进行发送。 以上各方案可根据自己公司的实际情况进行选择。
1K30发布于 2021-08-18 - 来自专栏程序员升级之路
实例讲解技术方案选型及落地
二、方案选型 上面这个问题是我最近看的一本书《从零开始学架构》里的一个例子，如果你是直接选择1，只能说大家还不到架构师的水平~，因为真实的方案需要考虑一些实际情况和约束条件的，书中举例的团队是这样的： 2、方案3也被排除，目前团队技术实力和人员规模还无法支撑自研存储系统。 3、方案3也有些问题，但都有相应的解决方案： 性能：业务目前性能不高，即使后面性能要求再增加，可以通过增加更多的组来扩容； 成本：大部分的Mysql从实例可以放在一台机器上，以节约硬件资源； 不够优雅 ：方案3看起来并不高大上，但我们做方案并不是为了追求高大上的东西，要能快速解决业务问题。 三、方案细化 针对方案3，上面只是大概的选型，到具体落地，还有很多工作要做，主要如下： 1、数据库设计 消息怎么存储，可以分2类，一是消息表，一是日志表； 这里还可以考虑不同业务隔离，采用分库分表，即一个大的业务单独一张表
1.5K10发布于 2021-06-10 - 来自专栏JavaEdge
监控场景及开源监控方案选型
先看监控的需求来源，即监控系统可做什么 再跳出监控，从可观测性，看监控与日志、链路间的关系及它们各自的作用 最后介绍开源社区几个有代表性的方案以及它们各自的优缺点，便于你之后做技术选型。 虽把可观测性领域划分3大支柱，但它们之间有很强关联关系。如经常会从日志提取指标，转存到指标监控系统，或者从日志中提取链路信息来做分析，业界都有实践。 3 解决方案横评 了解业界方案优缺点，对选型有大助。这里主要评价开源方案。 3.1 老代整体方案代表Zabbix 企业级开源解决方案，擅长设备、网络、中间件监控。 Open-Falcon最初来自小米，14年开源，当时小米有3套Zabbix，1套业务性能监控系统perfcounter。Open-Falcon初衷想做大一统方案，来解决这乱局。 最后对指标监控领域的多个开源解决方案横评对比，助技术方案选型。针对指标监控的几个开源方案的优缺点比较思维导图： 关注我，紧跟本系列专栏文章，咱们下篇再续！
1.2K10编辑于 2024-01-13 - 来自专栏架构之家
Redis 生产架构选型解决方案
在写开源项目的时候，想到了要支持多种redis部署方式，于是对于这块的生产环境的架构选型展开调研 一 引擎版本 推荐使用更新的引擎版本以支持更多的特性， Redis 6.0新特性说明 模块系统新增多个API 支持新的Redis协议： RESP3。 服务端支持多模式的客户端缓存。 支持多线程IO。 副本中支持无盘复制（diskless replication）。 Redis集群版提供1个、3个、5个只读节点的配置，相比标准版可以将QPS提升近5倍。
51440编辑于 2022-07-12 - 来自专栏架构之美
Redis 生产架构选型解决方案
支持新的Redis协议：RESP3。 服务端支持多模式的客户端缓存。 支持多线程IO。 副本中支持无盘复制（diskless replication）。 Redis集群版提供1个、3个、5个只读节点的配置，相比标准版可以将QPS提升近5倍。
51350发布于 2021-07-29 - 来自专栏码农沉思录
Redis持久化方案该如何选型
本文将先说明上述几种技术分别解决了Redis高可用的什么问题；然后详细介绍Redis的持久化技术，主要是RDB和AOF两种持久化方案；在介绍RDB和AOF方案时，不仅介绍其作用及操作方法，同时介绍持久化实现的一些原理细节及需要注意的问题 3) SELECTDB 0 pairs：表示一个完整的数据库(0号数据库)，同理SELECTDB 3 pairs表示完整的3号数据库；只有当数据库中有键值对时，RDB文件中才会有该数据库的信息(上图所示的 sadd myset v1 v2 v3。 前面介绍了RDB和AOF两种持久化方案的细节，下面介绍RDB和AOF的特点、如何选择持久化方案，以及在持久化过程中常遇到的问题等。 下面分场景来讨论持久化策略的选择，下面的讨论也只是作为参考，实际方案可能更复杂更具多样性。
1.4K20发布于 2018-07-23 - 来自专栏Java极客技术
浅谈本地缓存的几种方案选型
因为两者的数据存储方案不同，造就了不同的实践用途！ 我们上面讲到的缓存服务，其实本质就是将数据存储到内存中；而数据库服务，是将数据写入到磁盘，从磁盘中读取数据。 无论是哪种方案，没有绝对的好与坏，主要还是取决于实际的业务用途。 在项目中如何引入缓存呢？ 二、方案介绍 如果使用过缓存的同学，可以很容易想到缓存需要哪些东西，通常我们在使用缓存的时候，比较关注两个地方，第一是内存持久化，第二是支持缓存的数据自动过期清楚。 基于以上的要求，我们向介绍以下几种技术实现方案。 2.1、手写一个缓存服务 对于简单的数据缓存，我们完全可以自行编写一套缓存服务，实现过程如下！ 对于本地缓存的技术选型，推荐采用 Caffeine，性能上毫无疑问，遥遥领先。
73810编辑于 2024-04-25 - 来自专栏后端系统和架构
技术方案（开源方案）选型的考量和方法论
技术方案（开源方案）选型的考量和方法论我的观点：每个公司的情况不一样，开发人员的能力和语言也不一样，因此方案选型需要根据自身情况而定，没有最好，只有最合适！ 技术方案的选择需要团队内部的人员相匹配技术方案的实现是需要团队内部的开发人员来具体实施的，因此一定要考虑团队内的人员具体情况，并且所选择的技术方案需要和团队内部的人员相匹配。 比如当前这个方案技术人员是否接触过、编程语言是否熟悉、技术人员是否能够完全掌握这个方案等。 参照业界标杆选择技术方案（开源方案）业界标杆选择的技术方案，一定是经过他们专业人士对比、选型之后决策得到的，并且经过了他们的大量的线上实际验证的。 * 另外，对于不同业务体量和团队规模的公司，技术选型标准往往是不同的，创业公司的技术选型和 BAT 级别公司的技术选型标准可能完全不同。
87131编辑于 2023-02-15 - 来自专栏后端系统和架构
技术方案（开源方案）选型的考量和方法论
技术方案（开源方案）选型的考量和方法论 我的观点：每个公司的情况不一样，开发人员的能力和语言也不一样，因此方案选型需要根据自身情况而定，没有最好，只有最合适！ 技术方案的选择需要团队内部的人员相匹配 技术方案的实现是需要团队内部的开发人员来具体实施的，因此一定要考虑团队内的人员具体情况，并且所选择的技术方案需要和团队内部的人员相匹配。 比如当前这个方案技术人员是否接触过、编程语言是否熟悉、技术人员是否能够完全掌握这个方案等。 参照业界标杆选择技术方案（开源方案） 业界标杆选择的技术方案，一定是经过他们专业人士对比、选型之后决策得到的，并且经过了他们的大量的线上实际验证的。 • 另外，对于不同业务体量和团队规模的公司，技术选型标准往往是不同的，创业公司的技术选型和 BAT 级别公司的技术选型标准可能完全不同。
68530编辑于 2023-03-01 - 来自专栏Java架构师必看
最新技术选型解决方案列表
最新技术选型解决方案列表 1 概述 这是一份当前的技术选型方案，针对创业、中小型公司 2 目标 2.1 产品目标 2.1.1 SaaS 2.1.1.1 免安装 2.1.1.2 自我修复 2.3.6.1 丢失数据修复 2.3.6.2 内部异常流量控制 2.3.6.3 DDoS防护 2.3.6.4 漏洞修复 2.3.6.5 木马、后门修复 3 技术选型 3.1 数据库选型 3.1.1 MySQL 3.1.1.1 Natural key 和 Surrogate key Surrogate Key不允许修改。 3.3.1 CDN 静态资源 3.3.2 DNS 3.3.3 OSS/S3 3.3.4 SLB 3.3.5 Client – Browser 3.3.6 Envoy 3.5.3 Traefik 3.6 API网关选型 3.6.1 Kong 3.6.2 Sentinel 3.7 Service Mesh选型 3.7.1
1.4K40发布于 2021-07-12 - 来自专栏边缘计算
边缘计算云原生开源方案选型比较
在各行各业数字化转型和上云过程中，公有云厂商也在主动拥抱传统线下环境，在思考各种各样的解决方案使云上能力向边缘(或线下)延伸。 目前网上很少有从技术视角来介绍这几个项目优缺点的文章，本文试着从技术视角，从开源视角来分析这几个项目，希望可以给大家做项目选型时提供一些借鉴。 一键式转换等 根据架构差异对比和Kubernetes的能力增强点；主要关注边缘自治，边缘单元化，轻量化等能力 最后看一下架构差异可能带来的影响: 主要关注运维监控能力，云原生生态兼容性，系统稳定性等方面 （3） 边缘无轻量化解决方案: 虽然OpenYurt没有修改Kubernets，但是在边缘节点上增加YurtHub和Tunnel Agent组件。目前在最小的1C1G的系统上运行成功，更小规格机器待验证。 边缘计算场景 无设备管理能力：OpenYurt目前没有提供设备管理的相关能力，需要用户以workload形式来运行自己的设备管理解决方案。虽然不算是架构设计的缺点，但是也算是一个边缘场景的不足点。
2.3K20发布于 2021-03-10 选型踩雷3次后，我们总结了这份AllData选型清单
AllData大数据产品是可定义数据中台，以数据平台为底座，以数据中台为桥梁，以机器学习平台为中层框架，以大模型应用为上游产品，提供全链路数字化解决方案。 官方手册：https://www.yuque.com/aolingdata/product✨AllData正式环境：http://43.138.156.44:5173/ui_moat《 AllData选型清单
16921编辑于 2025-10-10- 来自专栏搜狗测试
软件性能测试方案-性能测试工具选型
前言 在往期文章《软件性能测试方案-性能测试准备》介绍了前期性能测试准备的要点，本文主要介绍性能测试工具的选型。 想象下，如果不使用工具进行性能测试会怎么样？ 性能测试工具选型参考 1.成本： 工具成本：工具通常分为商业（闭源）和非商业（开源）两种，商业工具通常功能比较强大、收费、可提供售后服务。开源工具通常是免费的、功能有限。 3.线性扩展能力： 调度能力有好有坏，有些性能测试工具调度能力特别强，具备很好的线性扩展能力，当压力不够的时候能够通过增加压力机数量的方式来线性的增加吞吐量、并发量，从而实现目标。 与上述wrk相比，vegeta本身具有以下优点和缺点： 优点： 1.安装、操作简单，易于使用； 2.单机支持能力强； 3.支持分布式压力测试； 4.可以用于测试固定吞吐量下的系统性能。 与上述wrk、vegeta相比，jmeter本身具有以下优点和缺点： 优点 1.界面可视化操作； 2.表格、图形、结果树等多类可视化数据分析和报告输出； 3.支持http、ftp、tcp等多种协议类型测试
9.1K20发布于 2019-10-15 - 来自专栏MySQL
10款常见MySQL高可用方案选型解读
关于对高可用的分级我们暂不做详细的讨论，这里只讨论常用高可用方案的优缺点以及选型。 二、高可用方案 1 、主从或主主半同步复制 使用双节点数据库，搭建单向或者双向的半同步复制。 该方案同样使用双节点架构，但是在原有半同复制的基础上做了功能上的优化，使半同步复制的机制变得更加可靠。 需要对源码有一定的了解，并能做一定程度的二次开发 依旧依赖于半同步复制，没有从根本上解决数据一致性问题 3 、高可用架构优化 将双节点数据库扩展到多节点数据库，或者多节点数据库集群。 比较常见的方案如下： MySQL Cluster MySQL Cluster是官方集群的部署方案，通过使用NDB存储引擎实时备份冗余数据，实现数据库的高可用性和数据一致性。 期望越来越多优秀的解决方案被提出，MySQL高可用问题也可以被更好的解决。
6.5K100发布于 2018-05-11 - 来自专栏多线程
【技术选型】Mysql和ES数据同步方案汇总
这其中有一个很重要的问题，就是如何实现Mysql数据库和ES的数据同步，今天和大家聊聊Mysql和ES数据同步的各种方案。 3、基于Mysql表定时扫描同步 上面两种方案中都存在硬编码问题，也就是有任何对mysq进行增删改查的地方要么植入ES代码，要么替换为MQ代码，代码的侵入性太强。 4、基于Binlog实时同步 上面三种方案要么有代码侵入，要么有硬编码，要么有延迟，那么有没有一种方案既能保证数据同步的实时性又没有代入侵入呢？ 当然有，可以利用mysql的binlog来进行同步。 缺点： 构建Binlog系统复杂； 如果采用MQ消费解析的binlog信息，也会像方案二一样存在MQ延时的风险。 请求后推送binlog日志给canal服务端，解析binlog对象（原始为byte流）转成Json格式 canal客户端通过TCP协议或MQ形式监听canal服务端，同步数据到ES 三、数据迁移同步工具选型
3.3K10编辑于 2023-12-14
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号