高并发就是大家臆想的吹牛逼，其实大部分业务场景不存在并发竞争数据的情况，那么加服务 加机器基本上都能解决问题，你要事务压力大 那就分表，要是查询压力大 就主从 + 缓存，总有办法解决问题的。

厕所里面 尽量不要出声 也不要打招呼，太尴尬了..

@bitholic #11 如果是 int 型的话 我可能就已经想出来了

@bitholic #11 并不是 上面要求的返回值是 double 类型，没要求 int 类型，double 类型的话 OJ 不太好判题

@xupefei #16 当时没想过，实际上不一定要相等才能结束迭代，可以差值在一个范围内 break 出迭代 也能返回一个近似值

@xuanbg #13 你运行一下试试 可以算准的，对于没法直接整数的 可能有误差

@also24 #9 面试的时候 没想到过 一般都是做的整数查找 迭代的终止条件比较清楚 mid == target
小数当时没有意识到，尴尬了..

@InkStone #6 我知道 3 楼那个写法也是一个选择..

@InkStone #4 指明了要用二分法..

@yuankui #1 这个解法是我事后想到的，出题的事后 他也没讲精度，没有精度约束的话 只能这样求解，但是我又不敢这样写。

@murmur #1 你不是果黑吗？

后端天花板高，但是前端容易接外包啊，随便写点 node 配合页面，外包就能做起来了。

..非计算机专业.. 本来发了面试邀请了，后来被 HR 筛了 有计算机专业硬性要求吗 3 年 Java 一直在互联网公司

或者可以针对订单 ID 做幂等性校验 把订单 ID 本地落库跟会员扣款放到同一个本地事务 commit 进数据库，做好隔离级别校验跟订单 ID 唯一性校验，如果有重复订单 ID 落库 直接吞掉异常 正常返回即可

@wysnylc #24 我看它的情况，会员系统应该本身应该就维护了 扣款 跟 会员权限配置 的事务操作，这本身就是一个本地事务，如果别人调你的话，你只要对外保证幂等性即可，一般分布式调用链会有 SpanId 调用 用来维护调用链的（像 SpringCloud-Seluth ），最好对 SpanId 做一个幂等性，有些中间件会在超时的时候做一些重试操作，很有可能单个订单会调用两次扣款操作

@wysnylc #24 很显然 楼主的场景跟楼主公司的业务量并没有那么大的规模，如果有的话 肯定不会轮到写代码的来排查这个问题了，在架构设计上就要避免了..

@btnokami #26 非常赞同..