- 综合排序
- 最热优先
- 最新优先
- 来自专栏音视频专栏
网络诊断方案选型
可用方案 （1）利用so库 执行底层的命令 （2）安装Linux层第三方库，使Android系统支持上述命令 （3）dnsjava 这两种方法分别有他们的缺点so库麻烦，并且体积大,而第二种方式需要root 现有网络诊断组件或者方案对比 （1）HttpInfo 比较强大，记录的信息包括 Index信息（域名以及请求时间） Net信息（手机网络信息） Ping信息 Http信息 Host信息 MtuScan信息 网络测速 满足大部分场景，代码公开，只有Android端 （3）LDNetDiagnoService_Android 功能：ping、tcp connect和traceroute Android的实现方案一 : 是通过后台线程执行ping命令的方式模拟traceroute的过程，缺点就是模拟过程较慢，timeout的出现比较频繁 Android的实现方案二: 通过编译开源网络检测库iputilsC代码的方式对 traceroute进行了套接字发送ICMP报文模拟，可以明显提高检测速度；（关于iputils工具原理实现，请参考博文） 这里用的方案2 （3）facebook/network-connection-class
4.8K60发布于 2020-08-04 - 来自专栏全栈程序员必看
Mongo分库方案选型
Mongo分库方案两种形式分析： 1. mongo sharding方式： 1.1.
44220编辑于 2022-09-12 - 来自专栏全栈程序员必看
无线充电器方案(方案选型)
目录 一篇读懂无线充电技术（附方案选型及原理分析） 0.背景 1.无线供电特点 1.1优点： 1.2 缺点 2. ： 4.1 IDT无线IC方案 4.2 恩智浦 MW系列无线充电IC方案： 4.3 TI （BQ系列）无线充电方案 4.4 东芝无线IC方案 5. 参考资料 博主热门文章推荐： 一篇读懂无线充电技术（附方案选型及原理分析） 作者：HowieXue 0.背景 现今几乎所有的电子设备，如手机，MP3和笔记本电脑等，进行充电的方式主要是有线电能传输，既一端连接交流电源 4.1 IDT无线IC方案 图：IDT无线发射与接收IC IDT公司的无线充电技术解决方案具备高集成度，提供单芯片SOC解决方案，支持QI-LOGOWPC认证，并且兼容POWERMATE模式；具有加密通讯 图：恩智浦MW系列无线充电IC 成本评估参考： 4.3 TI （BQ系列）无线充电方案 TI是最早量产无线充电方案公司。
2.2K21编辑于 2022-08-01 - 来自专栏battcn
Mock API技术选型方案
技术选型 当下互联网行业已经从大鱼吃小鱼演变成快鱼吃慢鱼的时代了，从用户需求转化成企业服务的能力，研发效能的高低对用户需求转化速率起到了至关重要的作用，而API服务的研发效能是当中非常重要的一环。 RAP2 长达1年+未更新维护，开源项目一档超过半年未迭代更新，选择就需要慎重，同时对比阿里对待开源的态度，不能商用大部分是KPI考核项目 如果是JAVA项目，可以采用 YAPI + Swagger 的方案
95830发布于 2021-09-23 - 来自专栏A周立SpringCloud
MySQL高可用方案选型参考
可选MySQL高可用方案 MySQL的各种高可用方案，大多是基于以下几种基础来部署的： 基于主从复制； 基于Galera协议； 基于NDB引擎； 基于中间件/proxy； 基于共享存储； 基于主机高可用 ； 在这些可选项中，最常见的就是基于主从复制的方案，其次是基于Galera的方案，我们重点说说这两种方案。 其余几种方案在生产上用的并不多，我们只简单说下。 基于主从复制的高可用方案 双节点主从 + keepalived/heartbeat 一般来说，中小型规模的时候，采用这种架构是最省事的。 在这个方案里，有几个需要注意的地方： 采用keepalived作为高可用方案时，两个节点最好都设置成BACKUP模式，避免因为意外情况下（比如脑裂）相互抢占导致往两个节点写入相同数据而引发冲突； 把两个节点的 老实说，我没实际用过，但从侧面了解到这种方案生产上用的并不多，可能也有些局限性所致吧； 以DBA们的聪明才智，肯定还有其他我不知道的方案，也欢迎同行们间多多交流。
1.3K10发布于 2019-07-10 - 来自专栏岛哥的质量效能笔记
弱网环境搭建方案选型
那今天来聊聊目前大致有哪些可以搭建弱网环境的方案以及各自存在的问题。 以上各方案可根据自己公司的实际情况进行选择。
96630发布于 2021-08-18 - 来自专栏JavaEdge
监控场景及开源监控方案选型
先看监控的需求来源，即监控系统可做什么 再跳出监控，从可观测性，看监控与日志、链路间的关系及它们各自的作用 最后介绍开源社区几个有代表性的方案以及它们各自的优缺点，便于你之后做技术选型。 3 解决方案横评 了解业界方案优缺点，对选型有大助。这里主要评价开源方案。 3.1 老代整体方案代表Zabbix 企业级开源解决方案，擅长设备、网络、中间件监控。 Open-Falcon初衷想做大一统方案，来解决这乱局。Open-Falcon架构图： Open-Falcon基于RRDtool做了一个分布式时序存储组件Graph。 容量问题，Prometheus默认只提供单机时序库，集群方案需要依赖其他的时序库。 最后对指标监控领域的多个开源解决方案横评对比，助技术方案选型。针对指标监控的几个开源方案的优缺点比较思维导图： 关注我，紧跟本系列专栏文章，咱们下篇再续！
96010编辑于 2024-01-13 - 来自专栏程序员升级之路
实例讲解技术方案选型及落地
二、方案选型 上面这个问题是我最近看的一本书《从零开始学架构》里的一个例子，如果你是直接选择1，只能说大家还不到架构师的水平~，因为真实的方案需要考虑一些实际情况和约束条件的，书中举例的团队是这样的： 可运维性 低，运维团队无Kakfa、Scala经验 高，运维对Mysql比较熟悉 高，可以融入运维体系 可靠性 高，开源成熟 高，Mysql存储很成熟 低，最初阶段难以保证 人力投入 低 中 高 即方案选型要从多个角度去考察 ：方案3看起来并不高大上，但我们做方案并不是为了追求高大上的东西，要能快速解决业务问题。 三、方案细化 针对方案3，上面只是大概的选型，到具体落地，还有很多工作要做，主要如下： 1、数据库设计 消息怎么存储，可以分2类，一是消息表，一是日志表； 这里还可以考虑不同业务隔离，采用分库分表，即一个大的业务单独一张表 ，可以采用SDK的方案，SDK会轮询各主服务器，将消息写入到相应的主服务器； 5、业务如何读消息 也是采用SDK的方式，服务端通过数据库保存消费者最后读取消息的位置 四、总结 技术选型需要考虑我们当前的一些现状态
1.4K10发布于 2021-06-10 - 来自专栏架构之家
Redis 生产架构选型解决方案
在写开源项目的时候，想到了要支持多种redis部署方式，于是对于这块的生产环境的架构选型展开调研 一 引擎版本 推荐使用更新的引擎版本以支持更多的特性， Redis 6.0新特性说明 模块系统新增多个API
44440编辑于 2022-07-12 - 来自专栏架构之美
Redis 生产架构选型解决方案
采用主从（master-replica）模式搭建。主节点提供日常服务访问，备节点提供HA高可用，当主节点发生故障，系统会自动在30秒内切换至备节点，保证业务平稳运行。
45350发布于 2021-07-29 - 来自专栏码农沉思录
Redis持久化方案该如何选型
本文将先说明上述几种技术分别解决了Redis高可用的什么问题；然后详细介绍Redis的持久化技术，主要是RDB和AOF两种持久化方案；在介绍RDB和AOF方案时，不仅介绍其作用及操作方法，同时介绍持久化实现的一些原理细节及需要注意的问题 最后，介绍在实际使用中，持久化方案的选择，以及经常遇到的问题等。 一、Redis高可用概述 在介绍Redis高可用之前，先说明一下在Redis的语境中高可用的含义。 集群：通过集群，Redis解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。 前面介绍了RDB和AOF两种持久化方案的细节，下面介绍RDB和AOF的特点、如何选择持久化方案，以及在持久化过程中常遇到的问题等。 下面分场景来讨论持久化策略的选择，下面的讨论也只是作为参考，实际方案可能更复杂更具多样性。
1.3K20发布于 2018-07-23 - 来自专栏Java极客技术
浅谈本地缓存的几种方案选型
因为两者的数据存储方案不同，造就了不同的实践用途！ 我们上面讲到的缓存服务，其实本质就是将数据存储到内存中；而数据库服务，是将数据写入到磁盘，从磁盘中读取数据。 无论是哪种方案，没有绝对的好与坏，主要还是取决于实际的业务用途。 在项目中如何引入缓存呢？ 二、方案介绍 如果使用过缓存的同学，可以很容易想到缓存需要哪些东西，通常我们在使用缓存的时候，比较关注两个地方，第一是内存持久化，第二是支持缓存的数据自动过期清楚。 基于以上的要求，我们向介绍以下几种技术实现方案。 2.1、手写一个缓存服务 对于简单的数据缓存，我们完全可以自行编写一套缓存服务，实现过程如下！ 对于本地缓存的技术选型，推荐采用 Caffeine，性能上毫无疑问，遥遥领先。
57410编辑于 2024-04-25 - 来自专栏后端系统和架构
技术方案（开源方案）选型的考量和方法论
技术方案（开源方案）选型的考量和方法论我的观点：每个公司的情况不一样，开发人员的能力和语言也不一样，因此方案选型需要根据自身情况而定，没有最好，只有最合适！ 技术方案的选择需要团队内部的人员相匹配技术方案的实现是需要团队内部的开发人员来具体实施的，因此一定要考虑团队内的人员具体情况，并且所选择的技术方案需要和团队内部的人员相匹配。 比如当前这个方案技术人员是否接触过、编程语言是否熟悉、技术人员是否能够完全掌握这个方案等。 参照业界标杆选择技术方案（开源方案）业界标杆选择的技术方案，一定是经过他们专业人士对比、选型之后决策得到的，并且经过了他们的大量的线上实际验证的。 * 另外，对于不同业务体量和团队规模的公司，技术选型标准往往是不同的，创业公司的技术选型和 BAT 级别公司的技术选型标准可能完全不同。
78931编辑于 2023-02-15 - 来自专栏后端系统和架构
技术方案（开源方案）选型的考量和方法论
技术方案（开源方案）选型的考量和方法论 我的观点：每个公司的情况不一样，开发人员的能力和语言也不一样，因此方案选型需要根据自身情况而定，没有最好，只有最合适！ 技术方案的选择需要团队内部的人员相匹配 技术方案的实现是需要团队内部的开发人员来具体实施的，因此一定要考虑团队内的人员具体情况，并且所选择的技术方案需要和团队内部的人员相匹配。 比如当前这个方案技术人员是否接触过、编程语言是否熟悉、技术人员是否能够完全掌握这个方案等。 参照业界标杆选择技术方案（开源方案） 业界标杆选择的技术方案，一定是经过他们专业人士对比、选型之后决策得到的，并且经过了他们的大量的线上实际验证的。 • 另外，对于不同业务体量和团队规模的公司，技术选型标准往往是不同的，创业公司的技术选型和 BAT 级别公司的技术选型标准可能完全不同。
57030编辑于 2023-03-01 - 来自专栏Java架构师必看
最新技术选型解决方案列表
最新技术选型解决方案列表 1 概述 这是一份当前的技术选型方案，针对创业、中小型公司 2 目标 2.1 产品目标 2.1.1 SaaS 2.1.1.1 免安装 2.1.1.2 3.1 数据库选型 3.1.1 MySQL 3.1.1.1 Natural key 和 Surrogate key Surrogate Key不允许修改。 Envoy 3.5.3 Traefik 3.6 API网关选型 3.6.1 Kong 3.6.2 Sentinel 3.7 Service Mesh选型 3.7.1 强一致性 3.9.4 Etcd 3.10 日志选型 3.10.1 ELK 3.10.2 Fluentd 3.10.3 Grafana Loki 3.10.4 Scalyr 3.11 追踪调用选型 3.11.1 OpenTracing 3.11.2 Zipkin 3.11.3 Jaeger 3.12 混沌选型 3.12.1
1.3K40发布于 2021-07-12 - 来自专栏边缘计算
边缘计算云原生开源方案选型比较
在各行各业数字化转型和上云过程中，公有云厂商也在主动拥抱传统线下环境，在思考各种各样的解决方案使云上能力向边缘(或线下)延伸。 目前网上很少有从技术视角来介绍这几个项目优缺点的文章，本文试着从技术视角，从开源视角来分析这几个项目，希望可以给大家做项目选型时提供一些借鉴。 边缘无轻量化解决方案: 虽然OpenYurt没有修改Kubernets，但是在边缘节点上增加YurtHub和Tunnel Agent组件。目前在最小的1C1G的系统上运行成功，更小规格机器待验证。 边缘计算场景 无设备管理能力：OpenYurt目前没有提供设备管理的相关能力，需要用户以workload形式来运行自己的设备管理解决方案。虽然不算是架构设计的缺点，但是也算是一个边缘场景的不足点。
2.2K20发布于 2021-03-10 - 来自专栏搜狗测试
软件性能测试方案-性能测试工具选型
前言 在往期文章《软件性能测试方案-性能测试准备》介绍了前期性能测试准备的要点，本文主要介绍性能测试工具的选型。 想象下，如果不使用工具进行性能测试会怎么样？ 性能测试工具选型参考 1.成本： 工具成本：工具通常分为商业（闭源）和非商业（开源）两种，商业工具通常功能比较强大、收费、可提供售后服务。开源工具通常是免费的、功能有限。
9K20发布于 2019-10-15 - 来自专栏MySQL
10款常见MySQL高可用方案选型解读
关于对高可用的分级我们暂不做详细的讨论，这里只讨论常用高可用方案的优缺点以及选型。 二、高可用方案 1 、主从或主主半同步复制 使用双节点数据库，搭建单向或者双向的半同步复制。 该方案同样使用双节点架构，但是在原有半同复制的基础上做了功能上的优化，使半同步复制的机制变得更加可靠。 可参考的优化方案如下： 双通道复制 半同步复制由于发生超时后，复制断开，当再次建立起复制时，同时建立两条通道，其中一条半同步复制通道从当前位置开始复制，保证从机知道当前主机执行的进度。 比较常见的方案如下： MySQL Cluster MySQL Cluster是官方集群的部署方案，通过使用NDB存储引擎实时备份冗余数据，实现数据库的高可用性和数据一致性。 期望越来越多优秀的解决方案被提出，MySQL高可用问题也可以被更好的解决。
6.5K100发布于 2018-05-11 - 来自专栏前端迷
基于 Express 应用框架的技术方案选型浅谈
服务篇会讲解一些基于 Express 应用框架的技术选型方案，这类技术往往对于做一些前端工具平台非常有用（例如 Mock 平台、多语言平台等，往往可配合命令行接口进行设计）。 这里简单介绍以前设计的几种基于 Express 扩展的技术选型方案，恰好涵盖了 React、Angular 以及 Vue 这三个 Web 前端框架。 React 技术方案选型 2016年7月到10月，从零开始学习 React 并使用 React 设计了服务端渲染的 Express 应用（同年10月25日诞生了 Next.js ），大致的技术选型如下： Vue 技术方案选型 2018年6月，使用 Vue 设计了服务端渲染的 Express 应用，大致技术选型如下： Mongoose Nuxt Vue lokka Muse-UI 客户端和服务端同构代码的 最后 设计了以上三个方案后，发现从零开始构建一个 Express 应用时至少需要考虑以下几个方面： 数据库( MongoDB / MySql 等)选型 是否需要模板引擎以及模板引擎( Ejs / Jade
8.1K30发布于 2020-06-01 - 来自专栏多线程
【技术选型】Mysql和ES数据同步方案汇总
这其中有一个很重要的问题，就是如何实现Mysql数据库和ES的数据同步，今天和大家聊聊Mysql和ES数据同步的各种方案。 如下图所示： 该方案的典型实现是借助logstash实现数据同步，其底层实现原理就是根据配置定期使用sql查询新增的数据写入ES中，实现数据的增量同步。 4、基于Binlog实时同步 上面三种方案要么有代码侵入，要么有硬编码，要么有延迟，那么有没有一种方案既能保证数据同步的实时性又没有代入侵入呢？ 当然有，可以利用mysql的binlog来进行同步。 缺点： 构建Binlog系统复杂； 如果采用MQ消费解析的binlog信息，也会像方案二一样存在MQ延时的风险。 请求后推送binlog日志给canal服务端，解析binlog对象（原始为byte流）转成Json格式 canal客户端通过TCP协议或MQ形式监听canal服务端，同步数据到ES 三、数据迁移同步工具选型
2.9K10编辑于 2023-12-14
腾讯云开发者
