网络编程包 - Magician 的原理与使用

Magician 是一个异步非阻塞的网络编程包，用 java 语言实现，支持 Http, WebSocket, UDP 等协议

运行环境

jdk11+

简单的原理介绍

Magician 的底层使用的是 NIO，但是没有用 Selector，因为 Selector 的设计初衷就是为了用单线程来处理高并发，从而减少因为连接太多而造成线程太多，占用过多的服务器资源。但是这样做的坏处也很明显，就是无法充分利用 cpu 的多核性能，还有一个就是如果业务比较耗时，会造成整个循环被堵住。

所以，考虑到这一点，Magician 决定使用 accept，代码如下：

while (true){
    SocketChannel channel = null;
    try {
        /* 这个方法会阻塞，直到有新连接进来 */
        channel = serverSocketChannel.accept();
        channel.configureBlocking(false);

        /* 将任务添加到队列里执行 */
        ParsingThreadManager.addTaskToParsingThread(channel);
    } catch (Exception e){
        logger.error("处理请求出现异常", e);
        ChannelUtil.close(channel);
    }
}

有一个 while 不断的监听 accept，当没有新请求进来的时候 accept 是阻塞的，所以不会有空轮询的问题，当有了新的请求进来，就会把 channel 丢到队列里面去，然后继续监听 accept 。

那么这个队列是什么结构的？他又是如何来执行的呢？

首先，队列的结构是这样的：他是一个 LinkedBlockingDeque，有序且长度无限（除非内存爆了），然后这个队列放在了一个线程中，线程开启后就会有一个 while 不断的从这个队列里 take 元素，如果队列为空，take 就会阻塞，队列一旦有数据 take 就会按顺序返回里面的元素。

所以，只要这个线程在运行，我们就可以不断的往队列里丢任务，让这个线程来慢慢消化。

如果这样的线程+队列有多个，我们把收到的请求通过轮询算法分配到这些队列，让线程各自消化，是不是就可以实现一个，线程数量可控，同时又具有异步特性的模型？

这个模型就是 Magician 现在所使用的，如下图所示：

在使用 Magician 的时候，可以自己配置需要几个线程来同时运行。

除了 http，udp 也是采用的这个模型。只不过 udp 是以同步的模式读数据，数据读完了再丢到队列里让队列去执行业务逻辑。

如何使用

说了这么多原理，我们接下来说说如何使用 Magician 来开发各种服务。

首先我们看一下 http 的实现

Magician.createHttpServer().httpHandler("/", req -> {

                        req.getResponse()
                           .sendJson(200, "{'status':'ok'}");

                    }).bind(8080).start();

如果不想把 handler 跟这段代码窝在一起，可以单独建立 handler，在这里添加进去即可

WebSocket 实现

Magician.createHttpServer().bind(8080)
                    .httpHandler("/", new DemoHandler())
                    .webSocketHandler("/websocket", new DemoSocketHandler())
                    .start();

只需要在创建 http 服务的时候，添加一个 WebSocketHandler 即可。

UDP 实现

Magician.createUdpServer()
                .handler(outputStream -> {
                    // outputStream 是 ByteArrayOutputStream 类型的
                    // 它是客户端发过来的数据，自行解析即可
                }).bind(8088).start();

同样的，也可以单独创建 handler，在这里添加进去

了解更多

想了解更多的话，欢迎访问 Magician 官网：http://magician-io.com

GuuJiang

2021-04-21 14:58:18 +08:00

既然难得你听得进去，那我就再多啰嗦几句

你这个东西不是基于现在已经指出的问题修修补补就能完成的，只能推倒重写，因为你的根本思路就是反的
作为一个网络框架，它的职责是什么，是负责网络 IO，所以要做的事情就是用尽量少的资源管理尽量多的连接，负责网络数据的读写，对于上层协议应该一无所知，也就是只实现 TCP/UDP 层，有数据可读就读，读到的数据直接丢给上层协议，至于协议数据什么时候完整，如何划分边界，得到业务数据后怎么进行业务处理，用什么线程模型，这些通通都是上层协议的事情，已经和网络层无关了，而你现在的思路是由协议层来主导读，我是一个 http 协议，所以我主动调 read 方法直到读到一个完整的 http 请求，我是一个 websocket 协议，那我就定时读取数据，这种思路首先只适用于 bio，其次也不推荐，这也就是我一开始说的，从 bio 到 nio 并不只是一个简简单单的 configureBlocking(false)就完事了，而是思路的转变

你真的想要实现一个网络框架，那最基本的能力之一就是使用者能自由扩充应用层协议，你确实可以内置一部分常用协议，但这种扩充应该是无侵入性的，更大的意义在于让使用者能开箱即用，同时对扩展协议提供参考
再回过头来看你图里的后半部分，我为什么管它叫线程池的雏形，因为它确实跟线程池的基本原理有点类似，但是很可惜实现也是错误的，你的队列和线程是一一对应的，这就导致线程无法得到充分利用，会出现有的线程空闲，而有的任务又被堵塞得不到处理，你可以去看看正确的线程池实现方式，给你点提示，看看队列和线程之间到底是什么关系

综上所述，你的这个东西，网络层和协议层之间的关系是错的，对 NIO 的使用方式是错的，线程池实现也是错的，并且这些错误都属于非常基础非常低级但是在初学者身上又很容易出现的，说实话，我发完第一条回复后好奇点了下你的发帖历史，我就已经后悔了，因为我看得出来你对自己的开源项目是非常自信的，但是很可惜你实际写出来的东西和你的自我认知之间存在非常巨大的差距，这样说也许很残忍，但是如果你继续在这条路上越走越偏直到哪天摔下来的时候，在隔壁帖子里对你表示过支持的所有人都有责任

Joker123456789

2021-04-22 14:09:43 +08:00

@GuuJiang

有问题就改嘛，直到成熟为止。什么东西不是一点点积累起来的呢，至于你说越走越偏那基本是不可能的，因为错的东西总会有暴露的时候，暴露出来后我就会立刻去改。我想不会有人来捧我这个素不相识的人吧？所以那种温水煮青蛙的情况你大可不必担心。

我发出来就是为了有你这样的人可以给我指点，所以你不必为我听得进去而感到惊讶。

然后可能我对这个东西的定位跟真正的网络包产生了冲突，这个应该是用词不当带来的问题。我对这个项目的定位就是一个支持 http，udp，webwocket 的服务包，我从来就不是走的 netty 的那条路，netty 应该是二次封装后的底层，可以比喻成 BIO,NIO,AIO 之后的又一个 IO （虽然那他是基于 NIO 的）。但是我做的这个是偏应用层的，你可以看做是一个极其微小的 tomcat，jboss 等。所以他不是你印象中的那种网络包，只是我用词不当导致的。

最后，你说线程池是错的，我有点不敢苟同，如果你把每个线程看作一台服务器，吧往队列里丢任务的那个进程看做是 nginx，你就大概明白这个思路了。如果这个算错误，那负载均衡不也是错的？有些服务器可能收到的请求比较轻松他执行的很快，有些服务器收到请求比较大执行缓慢，不也会导致部分服务器被堵死吗？所以负载均衡这种架构也是错的吗？

这个问题，我觉得加一个超时控制，或者把线程和队列分开？让空余线程来轮询或者随机消费其中一个队列？优化一下就好了嘛，只是一个有 bug 的东西，不至于彻底否认吧。

有问题就改问题，所以你如此的语重心长，苦口婆心，我是听进去了，但你不至于这样，这只是一个有 bug 和设计缺陷的不成熟项目而已，改就是了。

而且版本号你也应该看过吧，1.1.5, 这才哪到哪，现在基本只是处于一个能跑的状态，你对他的期望值过高也是我们产生矛盾的一个点。

网络编程包 - Magician 的原理 与 使用