<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Technical Summary &#8211; HU Xiaoxu</title>
	<atom:link href="https://blog.ihuxu.com/category/computer-science/technical-summary/feed/" rel="self" type="application/rss+xml" />
	<link>https://blog.ihuxu.com</link>
	<description>a software engineer&#039;s blog</description>
	<lastBuildDate>Sat, 21 Jun 2025 02:01:06 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.6.2</generator>
	<item>
		<title>自从有了她，再也不怕断签了：超级话题签到提醒</title>
		<link>https://blog.ihuxu.com/check-in-push-for-super-topic-at-weibo/</link>
					<comments>https://blog.ihuxu.com/check-in-push-for-super-topic-at-weibo/#respond</comments>
		
		<dc:creator><![CDATA[HU Xiaoxu]]></dc:creator>
		<pubDate>Tue, 25 Oct 2016 06:24:37 +0000</pubDate>
				<category><![CDATA[Computer Language]]></category>
		<category><![CDATA[Computer Science]]></category>
		<category><![CDATA[PHP]]></category>
		<category><![CDATA[Technical Summary]]></category>
		<category><![CDATA[Linux]]></category>
		<category><![CDATA[Original]]></category>
		<guid isPermaLink="false">http://www.ihuxu.com/blog/?p=7394</guid>

					<description><![CDATA[前言 在解决了上一次关于超级话题积分bug后，又接到超级话题签到提醒的产品需求。这是一篇偏于技术实现的文章，讲述的比较笼统，业务围绕超级话题的签到提醒进行展开。如果，您对超级话题签到提醒的技术背景与实现感兴趣，那么这篇文章希望对你有帮助。 当然，如果你是某个超级话题的超级粉丝，比如鹿晗，张艺兴，但是发现断签了。那么我非常替你感到“痛心”，因为目前超级话题没有补签功能。当然，如果你觉得是因为系统问题导致没有连续签到，那么你可以通过超级话题的官方反馈方式进行反馈来解决问题。当然，我劝你这么做之前一定要三思。因为，通过我排查的经验而言，基本山是由于你们（用户）把时间搞错了，而导致没有续签。而且，目前的签到提醒功能会在每天晚上提醒你签到的哦~ 产品 最近，在忙活超级话题的签到提醒产品的开发。首先，这是第一次比较热切的关注用户反应的产品。虽然说，对于产品的参与和认知并没有多么深入的理解，但是愈发的觉得这件事很有意识，也更想参与其中。 超级话题打破了传统话题的模式，以社区的形式展现，提高用户互动与粘性。其中，签到是不可或缺的一项功能。然而在前期，签到功能在给用户带来了高回访的情况下，也有着苦恼。作为研发同学，更是备受折磨。为什么？产品总是拿着反馈中自称经签过但却莫名断签的用户ID找我排查问题所在。然而，几乎都是一些凌晨时分签到而次日未签的情形。尽管是这样，用户的反感也是无法消除的。 为了不再做反复的排查劳动，只好做了一个相关查询后台。 产品同学为了召回用户，提供话题的UV和PV，提出了签到提醒的概念。 签到提醒会根据当前用户的签到行为，进行提醒私信的推送。目前为止，基本上每日需要提醒的量大约在85w左右。然而，在发送私信的过程中并非如此顺利。 技术 首先，要进行数据的准备。利用crontab定时将DB中的数据写入磁盘文件。之所以这么做，主要是由于DB中的数据是动态的，需要将数据写成静态的形式以更好的分批处理。 然仍采用crontab定时启动发送私信的脚本。将启动n个进程，同时处理上述步骤生成的n个文件。以curl_multi的方式批量调用话题粉丝服务的内部接口。 数据 超级话题提醒私信下发量：85W/日 超级话题提醒倒流UV：可观 下面的Redis服务中Key的曲线图，可以约等于下发的私信量： 问题 在形成上面的技术流程之前，也是经过了几番周折。 最初，以单进程的方式直接从DB读取数据，单次调用粉丝服务的接口进行发送私信。然而，在这种情况下，每日（2.5个小时）却只能发送5-6w的私信量。 由于压力主要在外部粉丝服务接口上，所以采取了批量调用的方式。利用PHP中的curl_multi，逢10批量调用粉丝服务接口。这样下来，每日（5.5个小时）能发送51w左右的私信。 然而，还是不能满足近100w的私信调用量。所以，增加了数据准备阶段。将数据写成静态文件，以多个进程的形式，同时处理文件以批量调用粉丝服务接口来发送私信。 在功能上线的第一天晚间，观察处理文件的进程“卡死”。 从上面两图可以确定，PHP进程卡死的原因在于读取MySQL服务中。进过排查处理后，程序得以进入正常流程。 目前为止，每日的调用量完全可以满足所需要发送的私信量。 用户 用户对签到提醒的反馈还是非常不错的，有图为证： 总结 针对于这种需要长时间运行与调用外部资源的脚本，最重要的就行要进行好完善的异常处理机制。由于PHP脚本的异常处理并非强制的，如果处理不妥到，会导致进程直接终止，排查起来也很困难。 同时，对于相关资源的监控也很重要。比如，当前机器的CPU资源，接口的平均响应时间，DB服务的相应时间等等。以确定每次执行期间相关资源的健康状态。]]></description>
		
					<wfw:commentRss>https://blog.ihuxu.com/check-in-push-for-super-topic-at-weibo/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>关于微博话题组软件构建与发布工程的分享</title>
		<link>https://blog.ihuxu.com/the-share-of-the-release-engineering-at-sina-weibo-topic-team/</link>
					<comments>https://blog.ihuxu.com/the-share-of-the-release-engineering-at-sina-weibo-topic-team/#respond</comments>
		
		<dc:creator><![CDATA[HU Xiaoxu]]></dc:creator>
		<pubDate>Sun, 14 Aug 2016 14:58:56 +0000</pubDate>
				<category><![CDATA[Computer Science]]></category>
		<category><![CDATA[Technical Summary]]></category>
		<category><![CDATA[Original]]></category>
		<guid isPermaLink="false">http://www.ihuxu.com/blog/?p=999</guid>

					<description><![CDATA[针对于“发布工程（Release Engineer）”，也许大家并不陌生。如维基百科中介绍： Release engineering, frequently abbreviated as RE or as the clipped compound Releng, is a sub-discipline in software engineering concerned with the compilation, assembly, and delivery of source code into finished products or other software components. Associated with the software release life cycle, it was said by Boris Debic of Google Inc. 对于一个有着庞大开发团队的成熟公司来说，构建工程显得格外重要。这样一个或者若干个由成百上千个开发成员支持的软件产品来说，构建与发布无非是非常严峻的考验。 然而，目前而言，我们团队在构建发布上仍有着很大的提升空间。 我们的问题 首先介绍下我们组。我们组负责微博的话题业务，每天有着成百上千万的访问量级。核心开发人员一共有 15 人左右。然而，尽管是 15 人的团队，软件的构建与发布流程也显得很重要。 在刚进入团队时，并没有构建概念，同样在发布流程上做的也不够衔接与完善。当有产品提出需求之后，技术 Leader 在进行需求拆分后合理分配给每个开发人员。之后，每个开发人员将以自己的姓名与时间从话题业务版本库的主干上 Check Out 一个分支。待开发完成之后，进入测试申请流程。常规情况下要进行三轮的测试：分支内网测试、分支仿真测试与主干回归测试。在这三轮测试顺利通过之后，我们将通过上线系统（QuikBuild）进入上线流程。 至始至终我们都遵循着上面的流程，然而，会发现如下问题。 面对上面的问题，我们及时地做了调整。首先，在会议讨论后，我们决定先在项目中融入持续集成与持续交付的概念。 发布工程<div class="read-more"><a class="btn read-more-btn" href="https://blog.ihuxu.com/the-share-of-the-release-engineering-at-sina-weibo-topic-team/">Read More</a></div>]]></description>
		
					<wfw:commentRss>https://blog.ihuxu.com/the-share-of-the-release-engineering-at-sina-weibo-topic-team/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
	</channel>
</rss>
