首页 注册 登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  sujin190  ›  全部回复第 61 页 / 共 122 页
回复总数  2428
1 ... 57  58  59  60  61  62  63  64  65  66 ... 122  
❮ ❯
2020-07-10 17:28:45 +08:00
回复了 sujin190 创建的主题 › Windows › 一直以为 windows 是磁盘读数据比写数据多，但是没想到啊，写数据来居然远远超过了读
@lxrmido #1 没啥场景，就看常规使用，浏览网页看视频工作，其实直觉一直以为会读远远超过写来着
2020-07-10 15:19:28 +08:00
回复了 xiangyuecn 创建的主题 › 问与答 › 新手如何当好一个韭菜？
既然如此，这么多软件都可以开模拟盘，还费那劲干嘛，虽然吧 1 万块本金和 100 百万本金其实是完全不同的
2020-07-10 09:37:47 +08:00
回复了 maobukui 创建的主题 › Python › 请教 Python 中 xml 转 dict 格式--不懂就问
dict 的 key 啥时候能重复了，你这是犯傻了还是想要逆天无视数据结构规则了
2020-07-09 09:39:15 +08:00
回复了 amiwrong123 创建的主题 › Java › ConcurrentHashMap 构造器为啥要这么处理？
@amiwrong123 #4 不是 2 的幂，你可以查一下大部分分配器的实现，大部分都是 2 4 8 16 32 这样分配的，倍数，虽然会浪费一些内存，但是内存碎片少，分配管理效率高
2020-07-08 23:28:12 +08:00
回复了 amiwrong123 创建的主题 › Java › ConcurrentHashMap 构造器为啥要这么处理？
内存对齐，还有现在大部分内存分配管理器都是 2 的倍数分配的，不这样处理那就白白浪费内存了
2020-07-07 22:35:09 +08:00
回复了 qazwsxkevin 创建的主题 › Python › 突发奇想， Python 与 mysql 的交互过程中，把 dict 类型保存在表中的一个字段里?
虽然读写起来是少了很多事，但是对于大多数业务来说，这也代表着逻辑不清，定义不明，结构不合理，缺少足够思考和理解，这不但脑懒还手懒，从维护来看真的是作死，如果经过了细致思考梳理设计，那么就应该每个字段每个数据定义逻辑都应该清清楚楚明明白白，既然如此那又犯这懒何必，借助良好的 ORM，使用上还更简单，关于性能不性能的，纯属想太多
2020-07-06 09:46:47 +08:00
回复了 tctc4869 创建的主题 › 程序员 › 各位现在常用 id 生成方案有哪些，使用策略是怎样的？
@opengps #1 但是事实上说的全是错的，纯属啥不懂还瞎 BB

分布式 ID 大多都是 Client 本地生成，算法基本逻辑大多是一样的，看最终字节数吧，8 字节估计大部分情况都需要手动配置 clientID，也就是集权机器进程 ID，16 字节一般也就可以直接本地取信息自动生成了，除此之外很多情况下还有希望是直接数字时间，比如订单号这样比较容易给人看的，但是这样的话直接占了 14 字符了，所以很多时候还是需要依据自己业务量来适当调整的
2020-07-04 21:33:52 +08:00
回复了 wangkun2012324 创建的主题 › 宽带症候群 › 好像最近的天翼网关 3.0 不能改桥接了，最近准备升级宽带，被告知新的光猫不能改桥接，坐标合肥
@iptables #19 看师傅的意思是看路由超级密码的权限被收回了，他们改啥都是和客服说，啥权限没有
2020-07-04 10:50:08 +08:00
回复了 wangkun2012324 创建的主题 › 宽带症候群 › 好像最近的天翼网关 3.0 不能改桥接了，最近准备升级宽带，被告知新的光猫不能改桥接，坐标合肥
江苏这边师傅修改的权限都被收回了，他们居然也是找客服改的，然后远程自动下发，上次给公司拉宽带，师傅担心光猫带不动这么多设备，想改桥接，在那找客服鼓捣了一天都没搞定，真是服了个服了

所以那么打客服应该也可以的吧，不行就让师傅帮你找客服
2020-07-04 10:41:29 +08:00
回复了 NightTeam 创建的主题 › 分享创造 › 忘掉 Snowflake！感受一下性能高出 587 倍的全局唯一 ID 生成算法
错漏百出，这都敢出来胡说八道，真行

首先 mongo 的 ObjectId 是本机生成的，谁说要写入库才有的，而且是单调递增的

分布式 ID 的首先需求是区分不同进程不同机器，不同机房，好嘛，直接把时间 bit 数加上去了，区分机器进程能力完全丧失，而且实际使用过程中，生成时间并不是平均的，有可能其中一毫秒内生成了几万几十万接下来好几小时都不用了，单毫秒内计数单字节，作死啊

Snowflake 需要手动配置集群机器进程 ID 作为一个分布式专用唯一 ID 生成算法就已经很不方便了，完全让一个微服务分布式系统无状态依赖变成了有状态依赖，而且是一个非常重要的依赖，作死啊，但是算法限制字节数 8 字节确实没用更好方法，但事实上强行限制字节完全没啥意义，多增加的成本并没有多少，但是一个完全无状态依赖又安全的分布式算法对于微服务分布式系统的意义就大多了，不知道省了多少事多少心

所以不清楚不知道还是别出来误人子弟瞎 bb 了
2020-07-03 09:59:46 +08:00
回复了 lalala139 创建的主题 › 汽车 › 科目二挂了三次了，心情太难受了，求 V 友安慰
据观察，考试的车如果看着不咋滴发动机比较弱，所以起步时如果先少放点离合接着放刹车略微给油，提高点发动机转速再放离合可以大幅度降低熄火概率啊，但是考试时你还得协调的过来，当时教练死活说的是先放离合到车身抖动放刹车简直被搞到死啊，动不动熄火，后来才发现这车太破教练自己放离合也给油
2020-07-02 17:22:40 +08:00
回复了 find456789 创建的主题 › 问与答 › Serverless 架构怎么保证代码不被泄露？
大部分情况来说，代码真不值钱，值钱的代码都是靠专利和知识产权保护的，所谓跑得了和尚跑不了庙，重点是云厂商别存在啥漏洞可以被第三方获取就好，而 Serverless 再多个账户间应该是完全隔离的，你不用担心运行的过程中被其他代码复制了，思维还是要换换啊，别老是代码代码啥的

而且吧 Serverless 倾向于专注高性能免维护小服务，基本单一部署的不具备啥完整性，你弄过去也用处不大啊
2020-06-30 16:34:19 +08:00
回复了 zht5178 创建的主题 › 宽带症候群 › 农村自建房网络布线的问题
从物理学来说，无线带宽越大的必然频率更高，然后穿墙能力越弱，满负载传输距离也更近，城市高楼的话还有无解的热点太多干扰问题，乡下没啥干扰还好点，有线则有这空间内更高叠加的优势，所以一行就算发展也应该时更多近距离更快无线 ap 节点才是，无论怎样都是有线更靠谱啊

其实吧，如果空间够，距离远各卧室似乎也没必要从弱电箱直拉啊，在楼上楼下再加交换机分就是了，带宽也足够了
2020-06-27 22:29:53 +08:00
回复了 EdmondYoung 创建的主题 › 职场话题 › 抽烟真的很重要吗
@EdmondYoung #10 所以不想抽就别抽呗，其实远没自己想的那么重要，自己所在的边远地区最近几年抽烟的都少了很多了，也几乎没有人会再强行给你的感觉了，大城市那更是，一屋子人你在里边抽烟绝对被人鄙视，没素质没教养，在我们这边其实想融入主动给被人敬烟也就不算失仪异类了，不想拒绝别人那就都接下来，但是别抽带走了处理了就是，反正也没人说你一定要在现场抽完吧，酒文化倒是重一些，串个门都先来三杯，大不了再看看情况适量多敬几轮酒就是了
2020-06-27 22:10:20 +08:00
回复了 EdmondYoung 创建的主题 › 职场话题 › 抽烟真的很重要吗
抽烟绝对陋习，看不顺眼就看不顺眼呗，理他个锤子，谁硬要塞那么这种人还是趁早拜拜了吧，而且吧有其他人的情况下还在室内抽烟也真真是绝对没教养没礼貌的恶劣行为，极其令人生厌

适量喝点酒还可以理解，虽然强行敬酒灌酒也是陋习，但是适量喝点酒确实可以快速融入，对身体也不算啥大坏处，可以理解
2020-06-25 16:55:47 +08:00
回复了 abcbuzhiming 创建的主题 › Java › 要针对特定的条件进行加锁时，用什么方式是最佳实践？
对用户 ID 进行加锁就是了啊，如果复杂业务的还可以以一系列信息生成 hash id 来加锁，除了多线程常规的单进程锁外，也可以用 redis 、zookeeper 之类的外部服务来加锁也很方便的

https://github.com/snower/slock

用 go 实现过一个能用于此种场景的小服务，能实现锁的语义还挺多的，性能也不错
2020-06-19 09:57:38 +08:00
回复了 yuzo555 创建的主题 › Serverless › 现在各大云厂商都在推广的 Serverless 产品，和当初的 GAE/SAE/BAE，甚至是更早的“虚拟主机”，主要区别在哪？
serverless 最大的特点本身就是把算法由被动等待服务变成主动服务，部署运维那些就不说了，对于云服务商来说资源利用率更高，对于你来说那些 90%不使用的时间都不用付钱了，再者互联网渗透率进一步加深后，空闲时间和繁忙时间两级差距进一步拉大，算法可以无状态自动化扩容自我维护这真的太需要了

虚拟主机完全没法比，且不说自动扩容免维护了，资源隔离都做不到，更别说啥资源利用率，说个锤子

SAE 算是不错了，但是其设计之初完全是基于 IDC 时代减少手动维护的思路设计的，并非是现在云和智能化运维思想的产物，其资源利用率，可维护性并没用得到很大进步，这也是价格还是很贵的原因之一吧，这就好比 SAE 勉强由手工时代进步到小作坊时代，serverless 则是流水线自动化大型工厂，没法比

而且可以预见，未来必定进一步完算法和运行环境分离，数据就是权力与资产，那么爆炸性的数据增长和极低门槛数据融合的进一步需求必然增加，serverless 或许是一个不错的基础
1 ... 57  58  59  60  61  62  63  64  65  66 ... 122  
❮ ❯
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2818 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 41ms · UTC 14:01 · PVG 22:01 · LAX 06:01 · JFK 09:01
Developed with CodeLauncher
♥ Do have faith in what you're doing.