科技新闻

第五章 高效的多线程日志 日志有两种意思： 诊断日志 交易日志 本章讲的是前一种日志，文本的供人阅读的日志，通常用于故障诊断和追踪，也可用于性能分析。 日志通常要记录： 收到的每条消息的id（关键字段，长度，hash等） 收到的每条外部消息的全文 发出每条消息的全文，每条消息都有全局唯一的id 关键部分状态的变更，等等 5.1 功能需求 日志库大体分为前端和后端两个部分 前端负责提供应用程序使用的接口API，并生成日志消息 后端负责把日志消息写到目的地 C++日志库的前端大体有两种API风格 printf的格式化输出风格 stream<<风格 stream风格的好处是当输出日志级高于语句的日志级别时，打印日志操作时个空操作，运行时开销接近零 分布式系统中的服务进程而言，日志的目的地只有一个：本地文件。往网络写日志消息时不靠谱的，因为诊断日志功能之一正是诊断网络故障，如果日志消息也是通过网络发到另一台机器就一损俱损… 本地文件作为destination，日志文件的滚动时必须的，可以简化日志的归档实现 文件大小（例如写满10GB就换下一个文件） 时间（例如每天零点新建一个日志文件，不论上一个文件是否写满） 日志文件压缩和归档，不应该是日志库应有的功能，应该交给专门的脚本去做 日志重复利用空间的功能，只会帮倒忙 往文件写日志的常见问题是，如果程序崩溃，最后几条日志信息就会丢失

web应用协议——HTTP HTTP（ 超文本传输协议） 一种通信协议， 1990 年提出， 当前版本为HTTP/1.1 使用超文本标记语言(HTML) 将资源从服务器传送到客户端 超文本传输协议特点 请求、响应模式 简单快速： 客户向服务器请求服务时， 只需传输请求方法和路径 灵活： HTTP 允许传输任意类型的数据对象。正在传输的类型由Content-Type 加以标记 无连接： 一个请求一个连接， 完成后断开 无状态： 协议对于事务处理没有记忆能力， 在服务器不需要先前信息时应答较快 HTTP协议结构 HTTP的一个会话， 由Request 和response 组成 HTTP 请求(Requests) 包含三个部分 请求行： 方法， URL, 协议/ 版本(Method-URl-Protocol/Version) 消息报头(Request headers) 请求正文（ Entity body) HTTP 响应(Responses) 也包含三个部分 状态行： 协议状态代码描叙(ProtocoI-Status code-Description) 消息报头(Response headers) 响应正文（ Entity body) 服务器返回的资源的内容 1 HTTP请求方法　　POST /servIet/defauIt.JSP HTTP/1.1

概述 听到这个名字是不是很熟悉，没错这个名字就是文学家卡夫卡的英文，传说中国的王小波也被誉为东方的乔伊斯+卡夫卡，哈哈哈，当然这篇文章不是谈论文学家卡夫卡的，那为什么一个消息中间件叫kafka呢？很简单就是这个中间件的作者喜欢卡夫卡，所以就这么命名了，如果有一天你也写出来一个牛逼的软件，而且你也很喜欢王小波，那你可以命名为xiaobo，没人可以拦得住你。 kafka架构 先上图（开篇一张图，内容全靠编） kafka broker : 从图中可以看出，这家伙是喜欢搞黄色的^_^，其实broker是kafka的基础存储单位，kafka所谓的分布式完全由多个broker一起组成的。 Topic ：这个图中没有体现，不过很简单，所谓的Topic就是消息，每个种类的消息都有一个topic，这就像你在数据库中要给学生建立一张表，给老师建立一张表一样。 Partition ：这个图中也没有体现，不过也很简单，有了Topic，你肯定要把Topic存储到broker中吧，既然broker有好多，那你不可能把一个Topic都存到一个broker里面吧，就像一个皇帝，怎么说也要做到雨露均沾，当然了，真实的原因并不是因为Topic喜欢瞎搞，而是因为这样可以提高吞吐量，一个节点肯定没有多个节点一起处理处理的快啊。那既然要分开存储就有了partition的概念

今日读了张银奎老师的《软件调试》，前面的CPU和硬件相关的部分离得比較远，所以从第九章操作系统读起，今天的读书笔记： 9.2採集调试消息 调试事件分为8种 typedef enum _DBGKM_APINUMBER { DbgkmExceptionApi = 0, // 异常 DbgkmCreateThreadApi = 1, // 创建线程 DbgkmCreateProcessApi = 2, // 创建进程 DbgkmExitThreadApi = 3, // 退出线程 DbgkmExitProcessApi = 4, // 进程退出 DbgkmLoadDllApi = 5, // 映射DLL DbgkmUnloadDllApi = 6, // 反映射DLL DbgkmErrorReportApi = 7, // 内部错误 DbgkmMaxApiNumber = 8, // 这组常量的最大值 } DBGKM_APINUMBER; 9.2.2 进程和线程创建消息 操作系统就支持向调试系统发送消息，这个我是没有想到的，详细步骤例如以下： 创建用户态windows线程时，首先为线程建立必要的内核对象和数据结构，并分配栈(stack)空间，这些工作完毕后， 该线程处于挂起状态(CREATE_SUSPEND), 而后进程管理器会通知环境子系统，环境子系统会作必要的设置和登记，最后

之前的博文中已经介绍过W5500EVB 在TCP模式下的两种（Server及Client）传输数据的实现过程，那么传输控制协议中，UDP也是很经常使用的。这样的无连接的协议在很多其它场合为用户提供了便捷。比方发电子邮件，QQ聊天发收消息等…好，那今天就学习一下。UDP模式在W5500EVB上的简单实现。 一 实验硬件及其连接 二 UDP实验相关知识 W5500是一款全硬件TCP/IP嵌入式以太网控制器，为嵌入式系统提供了更加简易的互联网连接方案。W5500集成了TCP/IP协议栈，10/100M以太网数据链路层（MAC）及物理层（PHY），用户无需特别关注TCP 和 UDP的实现过程。仅仅需最好对应配置和查询工作就可以。以下主要解说TCP和UDP差别。供參考 1 基于连接与无连接 TCP—传输控制协议提供的是面向连接、可靠的字节流服务。当客户和server彼此交换数据前。必须先在两方之间建立一个TCP连接，之后才干数据传输。TCP提供超时重发。丢弃反复数据，检验数据，流量控制等功能，保证数据能从一端传到还有一端。 每一个数据包的传输过程是：先建立链路、传输数据、然后清除链路。数据包不包括目的地址。受端和发端不但顺序一致，并且内容同样。它的可靠性高。 UDP—用户数据报协议是面向无连接的。每一个数据包都有完整的源、目的地址及分组编号，各自在网络中独立传输，传输中无论其顺序

文 | 陈肃 DataPipeline CTO 随着企业应用复杂性的上升和微服务架构的流行，数据正变得越来越以应用为中心。 服务之间仅在必要时以接口或者消息队列方式进行数据交互，从而避免了构建单一数据库集群来支撑不断增长的业务需要。以应用为中心的数据持久化架构，在带来可伸缩性好处的同时，也给数据的融合计算带来了障碍。 由于数据散落在不同的数据库、消息队列、文件系统中，计算平台如果直接访问这些数据，会遇到可访问性和数据传输延迟等问题。在一些场景下，计算平台直接访问应用系统数据库会对系统吞吐造成显著影响，通常也是不被允许的。 因此，在进行跨应用的数据融合计算时，首先需要将数据从孤立的数据源中采集出来，汇集到可被计算平台高效访问的目的地，此过程被称为ETL，即数据的抽取（Extract）、转换（Transform）和加载（Load）。 ETL并不是什么新鲜事物。 该领域的传统公司，例如Informatica，早在1993年就已经成立，并且提供了成熟的商业化解决方案。开源工具，例如Kettle、DataX等，在很多企业中也得到了广泛的应用。 传统上，ETL是通过批量作业完成的。即定期从数据源加载（增量）数据，按照转换逻辑进行处理，并写入目的地。根据业务需要和计算能力的不同，批量处理的延时通常从天到分钟级不等。在一些应用场景下，例如电子商务网站的商品索引更新，ETL需要尽可能短的延迟

一、概念 kafka是一个分布式的基于发布/订阅模式的消息队列，主要应用于大数据实时处理领域。 两种模式： 1.点对点： 一对一，消费者主动拉取数据，消息收到后清除。 2.发布/订阅模式： 一对多，消费者消费数据之后不会马上清除，可设置期限。 kafka是该模式下的基于消费者主动拉取消费的机制，比较浪费资源，一直轮询。 二、 来源： CSDN 作者： 东哥2020 链接： https://blog.csdn.net/dongfengpo25/article/details/104612369

1 警告：PerformSelector may cause a leak because its selector is unknown 原因：是因为你使用控制器来加载performSelector:方法导致，由于ios运行时在arc下的消息机制是根据方法的返回值来处理的，而使用performSelector:不确定返回值是什么类型的，因此会有警告。 处理方法： #pragma clang diagnostic push #pragma clang diagnostic ignored "-Warc-performSelector-leaks" [self performSelector:funcName]; #pragma clang diagnostic pop 未完待续 来源： oschina 链接： https://my.oschina.net/u/2682077/blog/706204

NSRunLoop类声明的编程接口对象管理输入源。NSRunLoop对象处理鼠标和键盘等输入来源来自窗口系统的事件,NSPort对象,NSConnection对象。还一个NSRunLoop对象流程NSTimer事件 - (void)addTimer:(NSTimer *)timer forMode:(NSString *)mode; + (NSRunLoop *)currentRunLoop; + (NSRunLoop *)mainRunLoop NS_AVAILABLE(10_5, 2_0); 消息处理模式，对消息处理过程进行了更好的抽象和封装 1.输入事件来源：输入源（input source）和定时源（timer source）.使用程序的某一特定的处理例程来处理到达的事件。 当你创建输入源，你需要将其分配给runloop中的一个或多个模式。模式只会在特定事件影响监听的源。大多数情况下，runloop运行在默认模式下，但是你也可以使其运行在自定义模式下。若某一源在当前模式下不被监听，那么任何其生成的消息只在runloop运行在其关联的模式下才会被传递。 传递异步事件，通常消息来自于其他线程或程序。输入源传递异步消息给相应的处理例程，并调用runUntilDate:方法来退出(在线程里面相关的NSRunLoop对象调用) 1.1 基于端口的输入源由内核自动发送

导读 当地时间6月15日下午6点25分，位于日本四日市的东芝5座NAND闪存晶圆厂发生断电事故，停电13分钟后恢复供电，但是生产线停工了5天，21日才恢复部分工厂运转，但Fab 2、Fab 3及Fab 4晶圆厂并没有恢复。 当地时间6月15日下午6点25分，位于日本四日市的东芝5座NAND闪存晶圆厂发生断电事故，停电13分钟后恢复供电，但是生产线停工了5天，21日才恢复部分工厂运转，但Fab 2、Fab 3及Fab 4晶圆厂并没有恢复。 东芝之前表态需要几天或者几周时间才能恢复，不过 最新消息显示东芝官方给出的恢复运营时间比预期的更长，预计到7月中旬才能完全恢复，意味着这次停电差不多会导致东芝闪存停产1个月时间 ，这下影响可比之前预期的大多了。 之前日本券商做过预测，假设断电影响的5家NAND工厂中有50%的晶圆受损，另有15%到20%的晶圆需要重新生产，那么这次事故将影响全球2-3%的NAND闪存供应量，不过那是基于停产5天来算的，现在是停产一个月左右，影响全球闪存供应的比例要提升到10%左右了。 东芝方面依然没有详细介绍这次停电事故带来的闪存产能影响，但停产一个月对东芝来说也是一次灾难了。此外，东芝的合作伙伴西数日前给出的损失预估是6EB，换算下来大约是1200万个500GB的SSD硬盘。 来源： oschina 链接： https://my.oschina.net/u